3. Processus de traitement des incidents
Une part fondamentale du travail des CASNSC est la réponse aux incidents. Tout centre d'assistance se doit de clarifier au préalable les étapes et les ressources nécessaires pour prendre en charge une demande d’assistance.
Le processus de traitement des incidents est continu et se déroule généralement selon les phases suivantes :
- Phase 1 : préparation
- Phase 2 : détection et analyse
- Phase 3 : endiguement, éradication et récupération
- Phase 4 : activité post-incident
Le processus de traitement des incidents ne doit pas se limiter à la phase d’endiguement, éradication et récupération : d'autres étapes doivent être suivies, par exemple lors de la phase de préparation et de celle de l'activité post-incident. Ce processus doit être documenté et organisé afin que les personnes chargées des incidents aient bien chaque phase en tête et soient en mesure de réduire les possibilités que le même incident se reproduise.
Il est très important pour un CASNSC de se doter d’un flux de travail commun et que chaque membre d’équipe connaît bien, afin de partager les tâches et de savoir quoi faire lorsqu’un incident a lieu, comment nous le traitons et comment nous travaillons phase après phase. Ceci doit être mis par écrit et ne doit pas être simplement une routine qui se produit, car cela mènera à des erreurs. Ce flux de travail n’est pas utilisé uniquement par nous, d’autres CERT l’utilisent, et il fait consensus ; il est également encadré de façon à tenir compte du type de bénéficiaires que nous aidons, ainsi que de nos capacités. Il aide donc toutes les personnes qui traitent les incidents à naviguer, de la détection à la récupération mais aussi à s’y préparer.
Hassen Selmi, chargé des réponses aux incidents, plateforme d’assistance pour la sécurité numérique d’Access Now (entretien, novembre 2021).
Retrouvez ci-dessous un schéma du flux de travail pour le traitement des incidents de la plateforme d’assistance pour la sécurité numérique d’Access Now.
Le processus de traitement des incidents devrait également être adapté aux besoins et au modèle de menaces du public de la ligne d'assistance. Par exemple, un CASNSC doit tenir compte du fait que les attaques ciblant la société civile sont habituellement sophistiquées et visent les personnes qui ne sont pas prêtes à de telles attaques. Un CASNSC devra donc se focaliser sur la phase de préparation et l'activité post-incident, pour aller au-delà d’une simple récupération et faire de l'incident une opportunité pour effectuer une prévention contre des attaques de ce type à l'avenir.
Nous avons constaté un niveau plus élevé de menaces avec un faible niveau de sécurité et d’autorité : nos centres d’assistance n’ont pas d’autorité sur les bénéficiaires. Nous pouvons recommander certaines choses, nous pouvons leur conseiller de faire certaines choses, mais il revient aux bénéficiaires de les faire ou non. La plupart du temps, nous travaillons à distance et il est très difficile de mener à bien exactement ce que nous aimerions mener à bien, comme les autres CERT d’autres secteurs le font, nous devons donc également nous adapter à cela.
Hassen Selmi, chargé des réponses aux incidents, plateforme d’assistance pour la sécurité numérique d’Access Now (entretien, novembre 2021).
Pour en savoir plus
- Exemple de plan de réponse aux incidents : NIST (2012). Computer Security Incident Handling Guide. Consultez les pages 21 à 44, pour plus d’information sur le processus de traitement des incidents.
- Kral, Patrick (2021). Incident Handler's Handbook. SANS Institute. https://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901.
3.1 Préparation
Le processus de traitement des incidents démarre lorsque l’on reçoit une demande : à ce stade, la personne chargée du traitement prend note des informations de base du cas, lui donne une priorité et une personne responsable et accuse réception de la demande à la personne qui l'a envoyée. Il faut ensuite procéder obligatoirement à une vérification pour s’assurer que la personne qui effectue la demande fait bien partie de la liste des bénéficiaires du CASNSC, et que le service demandé peut être fourni par le CASNSC.
Si la demande ne relève pas du mandat du CASNSC, le cas est clos, en envoyant éventuellement à la personne ayant effectué la demande une liste des alternatives disponibles. En revanche, si la demande relève bien du mandat du CASNSC, la vérification de la bénéficiaire est recommandée comme seconde étape préliminaire. Chaque CASNSC doit être doté d’une [politique de vérification] et la mettre en œuvre à ce stade, pour s’assurer que la personne bénéficiaire est bien qui elle dit être, et avant de traiter sa demande.
Une fois le mandat vérifié et la personne bénéficiaire filtré·e, le processus de traitement des incidents démarre, mais il faut aussi le préparer. La phase de préparation consiste à créer la documentation adéquate qui permettra de répondre rapidement à une série d’incidents connus et à former les personnels à suivre ces instructions (voir ci-dessous, section 3.5 Documentation des procédures).
Si vous examinez le schéma du flux de travail, il a l'air de démarrer avec le début de l'incident, mais en réalité et dans la pratique, la phase de préparation doit avoir continuellement lieu avant même l'apparition des incidents : c'est une phase proactive.
Hassen Selmi, chargé des réponses aux incidents, plateforme d’assistance pour la sécurité numérique d’Access Now (entretien, novembre 2021).
La phase de préparation comprend également les campagnes de sensibilisation et les formations auprès des bénéficiaires qui veulent mieux se sécuriser eux/elles-mêmes ou leur organisation. Lors de cette phase, un centre d’assistance peut également travailler à créer un réseau en nouant des liens avec d’autres fournisseurs de services ou en créant des partenariats avec d'autres lignes d’assistance et défenseur·es pour améliorer leur capacité à dériver les cas nécessitant une collaboration pour pouvoir être résolus.
Le travail consacré à la phase de préparation déterminera la rapidité, l’efficacité et la qualité de la réponse du CASNSC.
3.2 Détection et analyse
Dans l'idéal, un processus de réponse aux incidents démarre au stade de la préparation. Pourtant, dans la réalité, il commence à la deuxième phase du processus de traitement des incidents, lorsqu’une demande d’assistance est reçue.
La première étape de cette phase est la détection, qui vise à s’assurer que ce qu’observe la personne bénéficiaire est un véritable incident de sécurité numérique, autrement dit que le comportement observé par la personne en demande est bien anormal.
La personne qui traite l'incident doit demander à celui/celle qui l’a contactée toutes les informations disponibles : fichiers log du système et du réseau, captures d’écran, messages d’erreurs, rapports d'antivirus, emails suspects, symptômes perçus de changement dans le comportement normal, et autres preuves pouvant attester qu’un événement est bien un incident de sécurité. Les personnes traitant les incidents doivent être ouvertes à toute possibilité et ne pas laisser passer un incident de sécurité numérique.
Si la personne qui demande de l’aide est en situation de détresse émotionnelle, collecter les informations nécessaires à déterminer s’il s’agit bien d’un incident peut être revictimisant. Dans ces cas-là, toutes les données peuvent être collectées avec l’aide de la personne désignée par celui/celle qui effectue la demande d’aide.
L’étape suivante de cette phase consiste à analyser l'incident pour mieux comprendre ce qui se passe et quelles en sont les causes. Plus il y a de preuves, plus précise sera l'interprétation que pourra en faire la personne qui traite l'incident.
Différentes preuves peuvent être des symptômes d’un même incident ou de plusieurs incidents différents. Établir des corrélations entre preuves n'est pas une bonne chose, et peut mener à une mauvaise interprétation des faits. Pour éviter cela, vous pouvez effectuer une analyse de façon collective lors des réunions régulières pour discuter des incidents. Un outil pour démarrer l’analyse des problèmes les plus courants de sécurité numérique touchant la société civile est la [trousse des premiers soins numériques] (https://digitalfirstaid.org), une ressource gratuite qui aide les personnes chargées de la réponse rapide à résoudre les types d’urgences numériques les plus courantes.
Comme lors de la phase précédente, les personnes chargées de traiter l'incident doivent se souvenir d’enregistrer toutes les informations et de documenter toutes les mesures prises.
3.3 Endiguement, éradication et récupération
Une fois que vous avez confirmé que la personne bénéficiaire fait bien face à un incident de sécurité numérique, la personne chargée de l'incident procédera à la phase d’endiguement, éradication et récupération. La première étape est l’endiguement : une intervention pour « arrêter l’hémorragie », et veiller à ce que le cyberagresseur n’ait plus accès aux actifs numériques de la bénéficiaire. La personne chargée du traitement de l'incident fournit rapidement les instructions d'endiguement pour vite limiter les dégâts.
Bien entendu, la procédure requise pour l'endiguement se fonde sur le type d’actif ayant été attaqué. Pour en savoir plus sur les différentes procédures, un bon document en accès libre est la documentation de la communauté de la plateforme d’assistance d’Access Now.
L’éradication consiste à effacer tout ce que le cyberagresseur a pu ajouter. Ce n'est pas toujours facile car les individus malintentionnés sont habituellement très créatifs dans l’élaboration de nouvelles formes de cyberattaques.
Ensuite, l’étape de récupération entend restaurer les systèmes affectés et prendre les mesures nécessaires pour éviter de nouveaux incidents. Le suivi devient alors essentiel, afin de détecter toute autre méthode qu’un cyberagresseur pourrait employer et toute autre fuite de données. Les lignes d'assistance à la société civile ne pouvant souvent pas effectuer un suivi direct des actifs des bénéficiaires, cette étape peut être remplacée par la formation des bénéficiaires à effectuer eux/elles-mêmes ce suivi.
Parfois, un cas ne peut pas être clos par la personne qui en est chargée en raison d’un manque de temps ou de capacités. Dans cette situation, il peut s’avérer nécessaire d’impliquer d’autres membres du CASNSC pour transmettre le traitement du cas dans son intégralité ou en partie, en particulier avec l’analyse. C’est là que le réseautage et la collaboration entre différents CASNSC se révèlent particulièrement utiles.
3.4 Activité post-incident
La dernière phase du processus de traitement des incidents vise à recueillir ce que la personne qui a travaillé sur le cas a pu observer. Même si des possibilités d’atténuation des incidents de sécurité numérique ont pu être identifiées puis transmises au/à la bénéficiaire, de nouvelles façons d’approcher le problème ont pu surgir et ceci doit être documenté.
Les dernières étapes font également partie du processus. Si vous trouvez une nouvelle solution et que vous constatez que votre documentation ne s'est pas montrée aussi efficace que vous le souhaitiez pour aborder ce cas, en tant que personne chargée de traiter les incidents, il vous est également demandé de suggérer des solutions, en fonction de ce que vous avez vu. Il peut arriver que vous formuliez ces suggestions en amont du processus, car vous vous rendrez compte qu’un processus ne fonctionnera pas bien et qu’il aura besoin d’être amélioré.
Hassen Selmi, chargé des réponses aux incidents, portail d’assistance pour la sécurité numérique d’Access Now (entretien, novembre 2021).
Ces leçons apprises amélioreront la documentation du centre d’assistance, avec une approche plus créative et précise du traitement des incidents. Nous recommandons de ne pas retarder ce processus de documentation une fois le cas clos, car les petits détails ont tendance à être oubliés.
Parfois, un incident peut être connecté à une série d’attaques dont d’autres groupes de personnes devraient être averties, voilà pourquoi il est souvent nécessaire de disséminer et réseauter avec les partenaires à ce stade, afin de diffuser des alertes publiques décrivant ce genre d’incident aux cibles potentielles.
3.5 Documentation des procédures
Le terme de « documentation » est assez vaste. Il peut faire référence à plusieurs éléments, et s’il n’est pas clairement défini, il peut mener à des confusions. Dans la réponse à un incident, il existe deux types de documentation, tout aussi importants l’un que l’autre : la documentation des cas d’une part et la documentation des procédures, d’autre part.
La documentation des cas s'effectue généralement via le système de tickets d’assistance (voir section 2.5 Infrastructure et outils du chapitre 2) ou d'autres plateformes sécurisées. Elle consiste à prendre note de toutes les communications avec le/la bénéficiaire et de la façon dont la personne chargée du cas a décidé de la solution technique pour le résoudre, les preuves qui ont été recueillies, ce qui a mené à ces suggestions et quelles ont été les ressources consultées. Ceci permet de garder une trace de la façon dont le cas a été résolu, et si une nouvelle solution est trouvée, cela donnera lieu au second type de documentation.
Le second type de communication, qui est élaboré lors du stade de préparation du processus de traitement des incidents et réexaminé tout au long du cycle, est la documentation des procédures. Il s’agit de la documentation technique contenant les stratégies de résolution des incidents auxquels a fait face le public du CASNSC.
La documentation des procédures est cruciale au travail du CASNSC, car elle permet de garantir que les incidents sont correctement traités et que la qualité est assurée. En documentant ses procédures, votre équipe peut s’appuyer constamment sur une base de connaissances qui accélérera leur réponse. Par conséquent, les informations sur lesquelles s’appuient les personnes qui traitent les cas doivent être à jour et faciles d’accès.
Au stade de préparation du processus de traitement des incidents, nous essayons d'avoir à disposition une série d’articles ou de guides, qui nous permettront de répondre à des incidents que nous connaissons, que nous comprenons ou qui se sont produits dans notre ligne d’assistance ou chez d’autres organisations ou CASNSC. Nous essayons donc de les avoir toujours à portée de main, de former les personnes qui traitent des incidents à les suivre, et lorsqu’un incident correspond aux critères de cet article, nous le consultons. S’il existe de la documentation pour ce type d’incident, il faut que la personne chargée du cas la suive.
Hassen Selmi, chargé des réponses aux incidents, plateforme d’assistance pour la sécurité numérique d’Access Now (entretien, novembre 2021).
Ce chapitre se focalisera sur les différents aspects à prendre en compte lors de la création de la documentation de vos procédures de traitement des incidents : les principes fondamentaux, la planification, les plateformes et les formats, les stratégies de collaboration et les guides de style.
Les principes fondamentaux de la documentation technique
La création et la tenue à jour de la base de connaissances techniques d’un CASNSC sont un effort collectif continu, au sein des CERT et des lignes d’assistance mais aussi plus largement au sein de la communauté des organisations de sécurité numérique au service de la société civile. Ces efforts collectifs ont mené à l'adoption de certaines des bonnes pratiques établies dans l'industrie de la tech.
Qu’il s’agisse d’un guide utilisateur pour une appli mobile ou d’une entrée dans la base de connaissances incluse dans le système de tickets d’assistance de la ligne d’assistance, toute documentation technique, quelle que soit sa typologie, doit être :
- Participative : elle doit inclure toutes les personnes qui l’utiliseront, il faut donc que les moyens de collaborer soient clairs et qu’une trace des changements soit conservée et consultable.
- Actuelle et mise à jour: une documentation incorrecte peut induire encore plus en erreur que l’absence de documentation.
- Unique: la documentation devra être gérée à un seul endroit, pour éviter les incohérences entre les versions.
- Repérable : la documentation doit être pouvoir être trouvée lorsqu’on en a besoin.
- Compréhensible pour tou·tes les utilisateur·rices : il faut éviter tout jargon technique.
- Protégée des tentatives non autorisées de modification de son contenu.
- Facile à répliquer pour d’autres projets.
- Facile à déployer sous différents formats : comme les sites web, les applis mobiles, ou les fichiers PDF, entre autres.
Planification de la création de la nouvelle documentation
Un CASNSC peut documenter les solutions techniques à la fois pour les personnes chargées des incidents mais aussi pour leurs bénéficiaires, mais il peut parfois s’avérer nécessaire de rédiger pour les collaborations avec les partenaires, les campagnes de plaidoyer, les communications avec les médias, etc. En particulier dans le cas d’une documentation qui s’adresse aux utilisateur·rices sans formation technique, il vaut toujours mieux se demander si la solution spécifique que vous souhaitez documenter n'a pas déjà été présentée par d’autres sites internet de sécurité numérique réputés. Si c’est le cas, plutôt que rédiger en partant de zéro, vous pouvez par exemple mettre un lien vers une bonne ressource dans votre base de connaissances.
Avant de commencer à écrire, il convient de parcourir la documentation existante, autant pour vous assurer que vous ne dupliquez pas les efforts que pour avoir une idée claire des solutions techniques requises pour résoudre un incident particulier.
Une fois que vous avez une idée claire de ce que vous souhaitez écrire, essayez d’élaborer votre nouvelle documentation afin qu’elle puisse être utilisée dans d’autres cas, sans être spécifique au cas que vous venez de traiter. Pour ce faire, vous pouvez répondre à ces questions :
-
À qui s’adresse la documentation ?
Allez-vous envoyer cette documentation de façon individuelle aux emails de vos bénéficiaires ou allez-vous publier une annonce sur votre site web, afin que tout le monde puisse la lire ? Vous pouvez également rédiger pour d’autres personnes traitant les incidents et travaillant dans d’autres organisations, pour quelqu’un qui mène une campagne de plaidoyer ou même pour une intervention au cours d’une conférence spécialisée.
-
Que souhaitez-vous accomplir ?
Souhaitez-vous que les personnes qui traitent les incidents trouvent des solutions techniques rapides pour les cas auxquels leurs bénéficiaires sont confronté·es ? Ou rédigez-vous un modèle pour les messages que vous envoyez souvent à vos bénéficiaires ? Êtes-vous en train de préparer un avis de sécurité pour mettre en garde votre public concernant un nouveau genre de cyberattaque ? Ou souhaitez-vous préparer un rapport public qui peut être envoyé aux médias ?
-
Quel type de contenu répond le mieux aux besoins de votre public ?
Tenez compte du contexte de vos lecteurs et lectrices. Sont-ils/elles des professionnel·les de l'informatique ou des utilisateur·rices de base ? Ont-ils/elles besoin de détails techniques précis ou de simples instructions pas-à-pas avec des captures d’écran ? Sera-t-il nécessaire d’ajouter des images à votre guide ou serait-ce encore mieux de créer une vidéo ou une infographie ?
-
Comment votre public trouvera-t-il votre contenu ?
Ce contenu sera-t-il inclus dans votre système de tickets d’assistance ? Sera-t-il publié sur votre site internet ? Êtes-vous en train de créer un manuel qui deviendra un PDF imprimable ou une appli pour les dispositifs mobiles ? Votre contenu sera-t-il disponible en ligne et hors connexion ?
-
Le contenu va-t-il être traduit ou localisé ?
En fonction du public auquel vous vous adressez, vous voudrez peut-être traduire votre contenu dans les langues et les références culturelles qui sont les plus utilisées par les personnes que vous souhaitez atteindre.
Répondre à ces questions vous permet de définir le contenu, le style et le format de votre documentation. Par exemple :
- S’il vous faut mettre en garde votre public contre une nouvelle menace, il vous faudra rédiger rapidement et peaufiner votre message plus tard.
- Si le budget et les délais sont resserrés, vous devrez peut-être opter pour partager un texte simple avec les personnes concernées le plus vite possible, et penser à un format plus agréable lorsque les ressources seront disponibles.
- Si le public est vaste et le sujet complexe, une courte vidéo avec sous-titres peut s’avérer utile.
- Si vous rédigez des instructions techniques pour les personnes qui traitent les incidents, vous devrez inclure des détails techniques et mettre la documentation à disposition sur la même plateforme où vos équipes qui traitent les incidents documentent leur travail (ex. : le système de tickets d’assistance).
- Si vous rédigez une documentation qui peut être utilisée par d'autres organisations de la société civile, il est bon d’employer un langage simple qui peut être traduit facilement et de publier votre documentation avec une licence et dans un format qui peut être réutilisé.
Plateformes et formats de la documentation technique
L’outil le plus habituellement utilisé pour élaborer de la documentation dans le respect des principes fondamentaux évoqués auparavant, dans l'industrie informatique et au sein du mouvement offrant de la cyberprotection à la société civile est git, une technologie de contrôle des versions. Dans la plupart des cas, git est utilisé avec Markdown, un langage simple de balisage, et un générateur de site statique pour déployer le contenu dans un site web avec possibilité de recherche et facile d’utilisation.
Git pour le contrôle de version
Git est le logiciel de contrôle de version le plus communément utilisé pour rédiger de la documentation de façon collective. Sa principale fonctionnalité est de permettre aux utilisateurs d'avoir un suivi des modifications faites dans chaque fichier présent dans un dossier, afin qu’il y ait une trace de tout changement individuel. Il permet également de revenir à une version antérieure spécifique, si besoin.
Git facilite la collaboration en permettant de fusionner les changements faits par plusieurs personnes en une seule source. Une autre fonctionnalité utile de ce logiciel est la possibilité de protéger les identités des collaborateur·rices grâce à l’option de création de dépôts (repositories) privés, accessibles uniquement à un groupe d’utilisateur·rices sélectionné·es. De plus, il permet de signaler des problèmes, de gérer les contributeur·rices, d’attribuer différents rôles, de documenter le processus, d’accéder aux statistiques, etc.
La documentation gérée par le biais des dépôts git est habituellement hébergée sur des plateformes tierces comme Github ou Gitlab, ou en instances auto-hébergées de Gitlab. Voici plusieurs exemples de documentation élaborée sur git de façon collective par la société civile :
- La documentation de la plateforme d’assistance pour la sécurité numérique d’Access Now, déployée depuis ce dépôt de Gitlab.com.
- La trousse de premiers soins numériques, déployée depuis ce dépôt de Gitlab.com.
- SAFETAG - Security Auditing Framework and Evaluation Template for Advocacy Groups, déployée depuis ce dépôt de Gitlab.com.
Il existe nombre de ressources en ligne pour apprendre à utiliser git. Faites des recherches jusqu’à trouver celle qui s'adaptera le mieux à vos besoins d’apprentissage. Le [guide simple de git] (http://rogerdudler.github.io/git-guide/index.html) peut être un bon point de départ. Même si git n'est pas complexe pour un ou une contributrice régulière, il faut une certaine expérience pour se familiariser avec sa logique et ses commandes.
Markdown pour la rédaction
Dans les exemples ci-dessus, tous les documents sont rédigés dans Markdown, un langage de balisage léger créé par Aaron Swartz et John Gruber en 2004, pour permettre aux personnes « de rédiger le texte dans un format facile à lire et à écrire, puis de le convertir en XHTML (ou HTML) valide ».
Les documents Markdown peuvent être convertis en de nombreux formats, ce qui permet la création de sites web, applis mobiles, e-books et PDF en partant de la même source.
Il convient de signaler ici que même si la plupart des projets pilotés par la société civile utilisent Markdown, d’autres langages de balisage sont employés pour la documentation technique, en particulier AsciiDoc et reStructuredText (reST).
Si c'est la première fois que vous utilisez Markdown, vous pouvez avoir à portée de main une antisèche de syntaxe pour référence :
Générateurs de sites statiques pour créer des sites web
Pour convertir Markdown en sites permettant la recherche, les générateurs de sites statiques tels que Jekyll, Gatsby ou Metalsmith sont habituellement utilisés.
Les générateurs de sites statiques sont une alternative aux systèmes de gestion de contenus comme WordPress ou Drupa, où le contenu est géré et stocké dans une base de données sur le serveur web. Plutôt que de récupérer le contenu depuis une base de données chaque fois qu’une requête de contenu web est faite, le générateur de site statique déploie un site web entier après chaque mise à jour et crée un arbre de fichiers HTML prêt à être visité.
Un atout en plus de cette infrastructure basée sur git est le fait qu’elle est relativement simple à maintenir. Les sites statiques sont robustes contre les attaques et le trolling communs sur les plateformes telles que les wikis (en particulier si la possibilité de les modifier est ouverte à n'importe quel utilisateur) ou autres applications web ou sites web dynamiques, dont le maintien en sécurité requiert beaucoup de travail, tout comme le fait de veiller à ce que le contenu ne soit pas modifié de façon malveillante ou par erreur.
Documentation collaborative
L'utilisation d’une infrastructure de documentation basée sur git permet également à toute autre ligne d’assistance ou individu ayant accès à ce dépôt git d’utiliser la même base de connaissances pour créer son propre site web, appli mobile, e-book, etc., et également d’y recevoir et soumettre des mises à jour.
Ceci est rendu possible grâce à l'architecture même des hubs d’hébergement git comme Gitlab ou Github, qui permettent de faire une copie d’un projet et solliciter une fusion (ou « pull ») une fois que cela a été modifié dans la copie, ou « fork ».
Étant donné la quantité limitée de ressources disponibles dans la sphère de la société civile pour créer une documentation technique constamment mise à jour, collaborer sur des ressources de documentation technique partagées est devenu une pratique établie. Il faut alors éviter des formats qui ne sont pas faciles à télécharger ou dupliquer et qui ne prennent pas en charge le contrôle des versions, tels que les wikis, les sites web, les documents hébergés sur Google Drive, ou les PDF, et utiliser les licences de contenu de façon à permettre la collaboration et la création de travaux dérivés.
L’approche collaborative permet également d’éviter de dupliquer les efforts, les ressources existantes pouvant être réutilisées au lieu d’être écrites de zéro plus d’une fois.
Guide de style
La documentation des procédures techniques pour les CASNSC doit être rédigée dans une langue simple à lire et inclusive, en tenant compte du fait que les personnes qui traitent les incidents ne sont souvent pas anglophones de naissance, et que personne n’est expert·e sur tout, en particulier dans la sphère de la société civile.
En général, il est bon d’appliquer certaines grandes règles recommandées à toutes les personnes rédigeant des textes techniques :
- Écrire des phrases courtes qui semblent naturelles et simples.
- Utiliser du vocabulaire courant le plus possible, ne pas utiliser de jargon ou d’acronymes, sauf s’il est impossible de faire autrement (et dans ce cas, les expliquer au moins une fois).
- Ne pas oublier d’inclure tous les genres en utilisant des mots et pronoms de genre neutre.
- Utiliser une voix active (sujet + verbe + objet) le plus possible.
- Les listes sont un bon moyen de visualiser rapidement les informations.
- Insérer des liens vers des ressources externes, dans le cas où les bénéficiaires ont besoin de plus d’information sur une thématique.
De nombreuses ressources existent sur la façon de rédiger une bonne documentation technique. En voici juste une liste courte :
- Liste de ressources pour la rédaction technique dans Google's Technical Writing Courses for Engineers.
- Microsoft Style Guide