Communiquer avec le client et présenter les résultats

Le meilleur rapport du monde peut échouer s'il est simplement envoyé par courriel sans accompagnement, pour finir ignoré dans une boîte de réception surchargée. La communication autour des résultats d'un pentest est une compétence à part entière, aussi importante que la rédaction elle-même. Cette leçon vous donne des repères concrets pour la réussir.

Communiquer pendant la mission, pas seulement à la fin

La communication ne commence pas à la remise du rapport. Rappelez-vous les règles d'engagement du chapitre 1 : elles prévoient des points de contact et des conditions de notification immédiate pour toute découverte critique. Une mission bien menée inclut généralement :

• Un point de lancement, pour confirmer le périmètre et les contacts d'urgence ;
• Des points d'avancement courts, surtout sur une mission longue, pour signaler les blocages ou les premières découvertes importantes ;
• Une notification immédiate, par le canal convenu, en cas de faille critique découverte en cours de route, sans attendre la fin de la mission ;
• Un point de clôture, qui prépare la présentation finale.

Cette communication continue évite l'effet de surprise désagréable d'un rapport final qui révèle, après coup, un problème grave qui aurait pu être signalé et traité plus tôt.

Préparer la présentation finale

La remise du rapport s'accompagne presque toujours d'une présentation orale, en réunion. Quelques principes pour la réussir :

• Adapter le niveau de détail à l'audience présente : si des décideurs non techniques assistent à la réunion, commencez par le résumé et l'impact global avant d'entrer dans le détail technique ;
• Commencer par ce qui compte : les trois à cinq constats les plus importants, pas une liste exhaustive dans l'ordre où ils ont été trouvés ;
• Illustrer avec les chemins de compromission, qui parlent souvent plus qu'une liste de failles isolées, car ils racontent une histoire compréhensible ;
• Prévoir du temps pour les questions, et ne pas chercher à combler chaque silence par davantage de détails techniques ;
• Terminer par les recommandations et les prochaines étapes, pas par le constat le plus alarmant : une réunion qui se termine sur l'inquiétude sans perspective d'action laisse une impression négative et peu actionnable.

Gérer les réactions difficiles

Annoncer des failles de sécurité peut mettre en difficulté les équipes qui ont conçu ou géré le système testé. Quelques attitudes professionnelles aident à désamorcer les tensions :

• Séparer le constat de la personne : une faille documente un état du système à un instant donné, pas une faute individuelle ;
• Reconnaître ce qui fonctionne bien, pas seulement ce qui ne va pas : un rapport qui ne mentionne jamais un point positif paraît excessif et peut être perçu comme malveillant ;
• Rester factuel face à la contestation : si une équipe conteste un constat, proposez de vérifier ensemble les preuves, plutôt que d'argumenter sur le ton ;
• Garder à l'esprit l'objectif commun : améliorer la sécurité du système, pas « avoir raison » dans une discussion.

Le suivi après la remise du rapport

Un rapport remis n'est pas la fin de la relation professionnelle. Les bonnes pratiques incluent :

• Convenir d'un calendrier de correction réaliste avec le client, fondé sur les priorités établies ;
• Rester disponible pour clarifier un constat technique pendant la phase de correction ;
• Proposer, si c'est dans le contrat, une vérification après correction (souvent appelée « retest ») pour confirmer que les failles signalées ont bien été corrigées ;
• Conserver les preuves et le rapport de façon sécurisée, selon les modalités convenues dans le contrat, puis les supprimer au terme convenu.

Une vérification après correction est particulièrement précieuse : elle confirme que la correction appliquée traite réellement le problème, et pas seulement son symptôme apparent (par exemple, un correctif qui masque un message d'erreur sans corriger la faille sous-jacente).

Communiquer en cas d'incident imprévu pendant le test

Malgré toutes les précautions, un test peut parfois provoquer un effet inattendu : ralentissement, interruption momentanée d'un service. La bonne pratique, prévue dans les règles d'engagement du chapitre 1, consiste à :

1. Arrêter immédiatement l'action en cours ;
2. Prévenir sans délai le contact désigné, par le canal convenu ;
3. Documenter précisément ce qui a été fait juste avant l'incident ;
4. Attendre l'accord du client avant de reprendre, le cas échéant avec des précautions supplémentaires.

Cette transparence immédiate, même en cas d'erreur, est une marque de professionnalisme qui construit la confiance à long terme, bien plus qu'une tentative de minimiser ou de cacher un incident.

À vous de jouer : préparer une présentation de cinq minutes

En vous appuyant sur votre fiche de constat rédigée à la leçon précédente et sur le chemin de compromission construit au chapitre 6, rédigez le plan d'une présentation orale de cinq minutes pour un public mixte (un décideur non technique et un responsable informatique) : une phrase d'introduction sur le périmètre, trois points clés à présenter dans l'ordre, et une phrase de conclusion orientée vers l'action.

La communication réussie, il reste à toujours garder présente à l'esprit la question qui traverse tout ce cours : jusqu'où peut-on aller, et où doit-on s'arrêter ? C'est l'objet de la prochaine leçon.