Proposer un pentest : définir la mission et les résultats avant le devis

Un prospect souhaite un test d’intrusion et te demande un devis. Pour ton entreprise de cybersécurité, une décision concrète se présente : quelle application examiner, dans quelles conditions convenues, et quelle décision le client pourra-t-il prendre ensuite ? Un projet bien décrit relie le résultat recherché à un périmètre compréhensible. Le client peut comparer les propositions sur le fond, tandis que ton équipe technique dispose d’une base fiable pour sa planification.

Cet article s’adresse aux prestataires qui réalisent ces projets ou les proposent sous leur responsabilité professionnelle. Il traite du périmètre du devis, pas de la réalisation des tests. Le cas suivi est entièrement fictif : un éditeur veut faire examiner son portail clients avant une extension importante. Il mentionne une application web, plusieurs rôles utilisateurs et un hébergeur externe. Ton devis doit expliquer la mission qui en découle et les précisions nécessaires avant un éventuel démarrage.

Décrire la décision attendue après le test

Demande d’abord à quoi serviront les résultats. Dans l’exemple, la responsable produit souhaite décider quels problèmes identifiés traiter avant l’extension prévue. Cette mission diffère d’une simple vérification d’un constat déjà connu. La décision recherchée donne un objectif clair à ton devis et aide à identifier les destinataires des résultats.

Consigne cet objectif dans un court paragraphe. Décris la base que ton équipe peut fournir. Un rapport contenant des constats compréhensibles et une réunion de restitution peuvent y contribuer, si tu proposes ces prestations. Cela ne valide pas la sécurité de toute l’informatique de l’entreprise. Le client reçoit une information délimitée pour sa propre décision suivante.

Définir précisément l’objet examiné

« Notre portail » suffit pour engager une conversation. Un devis exige une désignation plus précise. Demande au client d’identifier l’application et son responsable. Clarifiez ensemble si le portail public, l’espace d’administration et une interface connectée appartiennent à la même mission. Les deux parties doivent partager la même compréhension du périmètre et reconnaître les points encore ouverts.

Dans le cas fictif, un autre partenaire exploite l’interface de facturation. Ton équipe la note donc comme un élément à clarifier séparément. Une connexion technique ne constitue pas à elle seule une mission convenue pour ce service. Le devis peut distinguer un périmètre central confirmé d’une extension nécessitant une coordination supplémentaire. Le client choisit ainsi consciemment les limites du projet.

Relier les rôles aux activités métier

Le nombre de comptes n’explique pas les différentes tâches à examiner. Demande plutôt quels rôles sont prévus et quelles activités ils accomplissent. L’exemple comprend un espace client et un traitement interne. Tu veux comprendre quels parcours le donneur d’ordre souhaite inclure. La sélection professionnelle et la profondeur précise des tests relèvent ensuite de la préparation technique qualifiée.

Dans le devis, rassemble rôles et activités dans des phrases compréhensibles. Évite les vrais identifiants de comptes et les données clients confidentielles dans le document commercial. Des désignations abstraites suffisent au départ. Si des comptes de test ou des informations supplémentaires deviennent nécessaires, ton équipe conviendra de leur fourniture dans le processus prévu pour le projet. Le commercial n’a pas à collecter des secrets d’accès.

Rendre visibles les informations et les hypothèses

Le client peut disposer d’une description qui ne couvre pas encore l’extension envisagée. Demande la date et le champ des documents disponibles. Indique les informations sur lesquelles repose ton devis et les questions ouvertes. Cela facilite la réponse du client et permet à ton équipe d’évaluer la cohérence entre préparation et examen proposé.

Dans l’exemple, la documentation décrit l’application actuelle. Un nouveau rôle apparaîtra seulement avec l’extension. Tu peux donc présenter deux décisions : examiner l’état actuel, ou clarifier davantage avant d’inclure aussi le futur domaine. Ton équipe technique évalue la pertinence au regard du projet réel. Le devis explique la dépendance sans déclarer prêt à examiner un état de développement inconnu.

Prévoir une mission écrite et les participants

Le guide de tests d’intrusion publié par le BSI allemand présente la mission écrite et la définition de l’objet, de la période et de la profondeur comme des bases organisationnelles. Pour la vente, la tâche pratique consiste à identifier le représentant du donneur d’ordre et les autres exploitants ou partenaires concernés. Les autorisations concrètes et les coordinations nécessaires sont établies pour chaque projet ; l’entretien commercial ne remplace pas cette vérification.

Dans le cas fictif, une coordination distincte avec l’hébergeur est nécessaire. Nomme un responsable et la précision attendue. Les accords confirmés doivent rester distincts des réponses en attente. Le client comprend alors pourquoi la date souhaitée dépend encore d’une contribution précise. Ton équipe sait également quelles conditions doivent être réellement confirmées avant la réalisation.

Relier le calendrier aux activités de l’entreprise

Une semaine de calendrier ne décrit qu’une partie de la collaboration. Demande quelles activités métier doivent être prises en compte et quand les responsables seront joignables. Dans l’exemple, la facturation mensuelle tombe pendant la période initialement demandée. La responsable produit et les responsables d’exploitation peuvent convenir d’un créneau plus adapté. Ta planification prend ainsi une dimension opérationnelle concrète.

Prévois aussi un circuit de communication convenu pendant le projet. Qui sera joignable chez le client, qui répondra dans ton équipe et comment traiter des effets inattendus ou une demande d’interruption ? Le détail relève de la préparation technique. Dans le devis, cette collaboration doit apparaître comme une tâche et correspondre à la prestation réellement proposée.

Adapter les livrables à leurs destinataires

La responsable produit a besoin d’une base claire pour planifier. Les développeurs ont besoin d’informations suffisamment concrètes pour comprendre et traiter les problèmes constatés. Interroge le client sur ces deux publics. Ton devis peut distinguer synthèse de direction, présentation technique des constats et réunion de restitution, si ces éléments font partie de ta prestation. Le client voit comment utiliser le rapport en interne.

Décris également le traitement convenu du rapport. Celui-ci peut contenir des informations sensibles sur l’application examinée. Destinataires, transmission et traitement ultérieur doivent donc être adaptés au projet. La phase commerciale peut nommer les responsables et le circuit restant à convenir. Elle n’a pas besoin de constats détaillés qui n’existent pas encore.

Expliquer ensemble constats et limites

Une description utile du résultat nomme le domaine examiné, son état et les conditions réellement convenues. Cela permet au client de comprendre ensuite la portée du rapport. Une interface non examinée reste expressément hors des conclusions. Le guide du BSI souligne les limites temporelles et matérielles de ces tests. Ta promesse doit les respecter tout en montrant l’utilité concrète de la mission.

Dans l’exemple, le rapport aide à prioriser les travaux sur le portail décrit, selon les conditions documentées. Il ne promet ni de trouver toutes les vulnérabilités ni d’empêcher les incidents futurs. Une modification ultérieure de l’application nécessite une appréciation distincte de son importance. C’est une question professionnelle de suivi, pas un résultat automatiquement vendu avec la mission initiale.

Clarifier le traitement des constats et la suite

Demande qui recevra les résultats et organisera les travaux internes. Dans l’exemple, la responsable produit coordonne la planification avec les développeurs. Ton devis peut inclure une discussion des résultats convenus. Une mise en œuvre ou une nouvelle vérification reçoit son propre périmètre si le client en a besoin et si tu la proposes. La première prestation reste ainsi compréhensible en elle-même.

Pour une contre-vérification, précise quel constat et quel état modifié devront être examinés. Reprendre tout le projet est différent d’une vérification ciblée convenue. Tu peux expliquer cette possibilité sans chiffrer une suite encore inconnue. Le client dispose d’un point de décision clair pour la prochaine phase.

Présenter le devis à partir du périmètre réel

Parcours le projet fictif avec le client dans un ordre stable : objectif, application, rôles, partenaires, informations fournies, calendrier et livrables. Fais confirmer chaque point ouvert par la personne réellement capable d’y répondre. Si une autre proposition inclut aussi l’administration, la comparaison des prix devient pertinente après clarification des différences de périmètre.

Explique la charge par le travail convenu. Préparation, examen professionnel et restitution remplissent des fonctions distinctes. Utilise ton calcul réel plutôt qu’un forfait générique emprunté à un autre exemple. Si le client modifie le périmètre souhaité, montre le poste concerné. Même après adaptation, il comprend quel résultat son achat lui apporte.

Faire avancer une question ouverte vers une décision

Le devis doit enfin déboucher sur une action concrète. Dans l’exemple, la réponse de l’hébergeur sur le domaine envisagé manque encore. Note qui l’obtiendra et quelle décision pourra suivre. Une relance ciblée peut alors porter exactement sur ce point. Le client n’a pas à répéter toute sa situation ni à choisir entre plusieurs étapes floues.

Cette démarche peut servir pour d’autres projets applicatifs dans les limites de ton offre réelle. L’essentiel reste le lien entre une question métier, un objet d’examen explicite et un résultat utile. Tu rends ta compétence visible pendant la vente et prépares une collaboration dont chacun comprend le périmètre. Les spécialistes qualifiés restent responsables de la réalisation technique et des précautions propres au projet.

Traiter clairement une demande supplémentaire

Pendant la discussion, le client ajoute que son outil administratif interne l’intéresse aussi. Demande d’abord s’il appartient à la même application ou constitue un système exploité séparément. Indique ensuite les précisions et les participants nécessaires à son évaluation. Le client peut choisir entre clarifier cette extension maintenant et poursuivre la mission centrale déjà décrite. Ce choix reste compréhensible même sans estimation fiable de la charge supplémentaire.

Documente la décision avec la version du devis. Un lecteur ultérieur doit distinguer la demande intégrée de celle simplement évoquée. Produit, achats et équipe projet conservent la même base. Une information nouvelle modifie la partie concernée de l’accord sans élargir silencieusement l’engagement de tout le projet.

De nouvelles demandes pour tes prestations de cybersécurité

webRichtung fournit des demandes de cybersécurité avec besoin exprimé, environnement, stade actuel, localisation et contact de l’entreprise en Allemagne. Tu précises personnellement le périmètre d’un pentest ensuite ; les rapports, inventaires et identifiants d’accès ne sont pas collectés par la demande. Inscris ton entreprise sur la page des leads de cybersécurité. Dans webRichtung Customer, tu vois le prix actuel avant toute commande ferme.

Sources

BSI : Guide de réalisation des tests d’intrusion, novembre 2016, sections 1.4.2, 2.3 et 4.1.3. Lu le 18 octobre 2026 ; contexte organisationnel, pas de procédure technique actuelle ni de conseil juridique.