PREUVE / Feuillet de consultation

Scan de vulnérabilités ou pentest : choisir une preuve adaptée au client

Mis à jour le 1er octobre 2026

Distinguer les méthodes et leurs livrables

Un scan utilise des outils pour rechercher des signes de vulnérabilités dans une surface définie. Un pentest implique une démarche de test et d’analyse dans un cadre autorisé, avec des scénarios adaptés au périmètre. Les outils peuvent faire partie du pentest ; leur présence ne décrit pas à elle seule la prestation. Demandez au cabinet ce qui est automatisé, ce qui est examiné par un auditeur et comment les résultats sont qualifiés.

Le client grand compte peut demander explicitement un rapport de pentest. Acheter un scan à la place sans lui faire valider cette substitution risque de produire une preuve refusée. Commencez par sa clause, puis décrivez les fonctions et les droits sensibles. La comparaison doit porter sur la question à résoudre et les livrables, sans dévaloriser un outil utile pour un autre besoin de surveillance.

Examiner les autorisations et la logique métier

Un outil peut repérer certains composants ou configurations connus. Il ne comprend pas nécessairement les règles métier de votre produit. La séparation entre organisations, les délégations ou les opérations d’approbation demandent une description du comportement attendu. Un pentest applicatif peut examiner ces scénarios avec des comptes et données fictives, selon le contrat et le temps prévu.

Prenons un exemple fictif : un rôle peut lire un document mais ne devrait pas l’exporter après révocation d’un partage. La vérification nécessite de connaître la règle, le changement d’état et les chemins concernés. Un résultat de scan sans contexte ne démontre pas cette propriété. Le cabinet doit préciser comment il couvre ce type de scénario et ce qui reste hors mission.

Lire les limites des résultats

Un scan peut produire des alertes qui nécessitent une qualification, ou manquer des défauts qui dépendent d’un état applicatif. Un pentest a lui aussi des limites de couverture, de période et d’accès. Aucun des deux ne garantit l’absence de vulnérabilité. Le rapport doit décrire la méthode, les exclusions et les difficultés rencontrées. Une formule générale « aucun risque » ne correspond pas à une évaluation bornée.

Demandez comment les constats sont reproduits et contextualisés. Les preuves doivent être adaptées à la sensibilité des données. Une liste d’alertes brutes n’a pas la même valeur opérationnelle qu’un rapport qui explique les conditions, l’impact et les pistes de traitement. Pour l’acheteur, la qualité de la synthèse et la traçabilité du retest peuvent compter autant que la méthode initiale.

Combiner les contrôles

Un scan récurrent peut aider à suivre certains changements de surface ou de configuration. Les contrôles de développement et les revues de code peuvent traiter d’autres questions. Un pentest ponctuel apporte une analyse sur les scénarios retenus. Construisez une démarche où chaque contrôle a un objet explicite. Il n’est pas nécessaire de présenter tous les outils comme des pentests pour justifier leur utilité.

Les alertes doivent être traitées par des responsables identifiés. Une détection sans qualification ni correction n’améliore pas à elle seule la preuve remise au client. Le CTO définit les critères de suivi et les événements qui déclenchent une mission complémentaire. Le commercial utilise les documents réellement disponibles, avec leur date et leur portée.

Comparer les propositions

La consultation demande la surface, les rôles, les scénarios, la méthode humaine, les outils, le rapport et les conditions de reprise. Vérifiez les exclusions : API, multi-tenant, fonctions administratives et intégrations. Une offre courte peut convenir à un inventaire de surface mais pas à une clause d’audit applicatif. Une offre plus large doit être justifiée par le besoin plutôt que par une promesse de couverture totale.

Faites accepter le format par le grand compte avant commande. Si un scan est retenu pour une première phase, indiquez ce qu’il apporte et ce qu’un complément devra couvrir. Le devis distingue les livrables et les limites de chaque phase. Aucun nombre de vulnérabilités, tarif de marché ou taux de détection n’est inventé dans cette comparaison.