Un cabinet de conseil en gestion de patrimoine, dont le site avait subi une compromission via une extension de formulaire de contact obsolète, a reçu un rapport de remédiation qui reprenait initialement, presque mot pour mot, les termes techniques utilisés en interne pendant l’intervention : « webshell », « payload », « persistence via cron ». Le client, légitimement inquiet, a demandé une reformulation complète avant de pouvoir prendre une décision sur la suite à donner à la relation avec son hébergeur.
Cette expérience a conduit à revoir entièrement la structure des rapports de remédiation destinés à des clients non techniques, en s’appuyant sur un principe simple : le rapport doit permettre à quelqu’un sans aucune connaissance en développement de comprendre ce qui s’est passé, ce qui a été fait, et ce qui change pour l’avenir, sans avoir besoin de faire traduire le document par un tiers.
Structurer en trois blocs distincts
La structure qui a fonctionné repose sur trois sections clairement séparées, dans cet ordre précis : ce qui s’est passé, ce qui a été fait pour corriger la situation, et ce qui change désormais pour éviter une récidive. Mélanger ces trois temps dans un même paragraphe, comme c’est souvent le cas dans un rapport rédigé dans l’urgence, brouille la lecture et laisse le client incapable de distinguer le diagnostic de la solution.
Bloc 1 : ce qui s’est passé, sans minimiser ni dramatiser
Cette section décrit factuellement l’incident, avec une date précise et une portée clairement délimitée, sans jargon :
Le 14 juillet, une extension installée sur votre site permettait à une personne extérieure d’ajouter du contenu sans autorisation. Cette faille a été utilisée pour publier des pages non visibles depuis votre menu, orientées vers un autre site. Aucune donnée de vos visiteurs ni de vos clients n’a été concernée par cet incident.
Cette formulation évite deux écueils opposés : minimiser au point de faire perdre confiance si le client découvre l’ampleur réelle par un autre biais, et dramatiser au point de provoquer une inquiétude disproportionnée par rapport à l’impact réel.
Bloc 2 : ce qui a été fait pour corriger la situation
Cette section liste les actions concrètes entreprises, en évitant les termes techniques quand une reformulation simple existe :
- Le contenu ajouté sans autorisation a été identifié et supprimé
- L’extension à l’origine de la faille a été mise à jour vers une version corrigée
- L’ensemble des mots de passe d’accès au site a été renouvelé par précaution
- Une vérification complète des autres extensions installées a été menée, sans anomalie supplémentaire constatée
Bloc 3 : ce qui change pour l’avenir
Cette dernière section rassure sur la prévention, sans promettre une sécurité absolue qui n’existe jamais réellement :
Une surveillance automatique des mises à jour de sécurité a été mise en place, avec une vérification hebdomadaire de l’état des extensions installées. Ce type d’incident reste possible sur tout site web, mais le délai de détection et de correction est désormais nettement réduit.
Fournir une date et un contact clair
Le rapport se termine systématiquement par une date précise de résolution complète et un contact direct pour toute question complémentaire — un point simple, mais souvent oublié dans un rapport rédigé rapidement après une intervention technique intense, où l’attention se porte davantage sur le contenu que sur la forme finale du document.
Ce qu’il faut éviter dans ce type de rapport
| À éviter | À privilégier |
|---|---|
| « Un webshell a été détecté et neutralisé » | « Un accès non autorisé a été identifié et fermé » |
| Liste de CVE et de versions techniques | Résumé en une phrase du type de faille, sans référence technique |
| Rapport de plusieurs pages avec extraits de code | Une page, structurée en trois blocs courts |
Le cas du client qui demande plus de détails
Certains clients, notamment ceux ayant une culture technique même limitée, demandent naturellement plus de détails après lecture du rapport simplifié. Prévoir une annexe technique optionnelle, transmise uniquement sur demande, permet de satisfaire cette demande sans alourdir le document principal destiné à la majorité des clients qui n’en ont pas l’usage.
En résumé
Un rapport de remédiation compréhensible ne consiste pas à simplifier à l’excès la gravité d’un incident, mais à séparer clairement le constat, l’action corrective et la prévention future, dans un vocabulaire dénué de jargon technique. Cette structure en trois blocs, testée sur plusieurs incidents de nature différente, a systématiquement rassuré des clients qui, sans elle, seraient restés avec une compréhension floue et anxiogène de ce qui s’était réellement passé.
