Créer un guide de rédaction (pour l'anglais)

illustrations illustrations illustrations illustrations illustrations illustrations illustrations

Publié le 25 août 2022 par Andrew Owen (7 minutes)

post-thumb

Lorsque je suis passé du journalisme à la rédaction technique, les deux choses qui m’ont le plus manqué sont les guides de style et les rédacteurs. Lorsque les services de rédaction technique sont réduits, les rédacteurs sont les premiers à être licenciés. À trois reprises, quand j’étais le seul rédacteur d’une organisation, j’ai créé mon adéquat guide de style à partir de rien. Mais même quand il existe un guide de style, il peut ne pas être à jour en ce qui concerne la terminologie moderne ou l’utilisation du langage. Si votre travail consiste à rédiger des contenus destinés aux clients, surtout si vous n’avez pas suivi de formation de rédacteur, vous avez besoin d’un guide de style.

Lorsque j’ai débuté dans la rédaction technique, à moins de travailler pour Apple ou Sun, le “Manuel de style Microsoft pour les publications techniques” (3e édition) était le guide de style le plus couramment utilisé. Et il était dépassé d’une décennie et n’avait rien d’utile à dire sur l’internet. Je pense que les captures d’écran datent de Windows 95. Il n’a pas été mis à jour avant 2012. L’autre référence stylistique était le “Chicago Manual of Style”, qui était destiné aux universitaires et n’avait rien d’utile à dire sur l’internet jusqu’à sa 16e édition (publiée en 2010).

Le troisième ouvrage de référence était un dictionnaire. À moins de travailler pour Apple ou Sun, ou pour une entreprise britannique, il s’agissait du “Merriam-Webster’s Collegiate Dictionary”. À l’insu de la plupart des Britanniques, il existe deux conventions orthographiques distinctes pour l’anglais britannique: Oxford (qui préfère les terminaisons en -ize pour les mots d’origine grecque ou romaine) et Cambridge (qui préfère les terminaisons en -ise introduites par les Français). À l’exception du Canada (qui mélange American et Cambridge), les anciennes colonies ont opté pour les terminaisons en -ise.

Si vous n’avez pas encore de guide de style, vous devriez en créer un. Mais il n’est pas nécessaire de partir d’une feuille blanche. Il s’agit d’un court document qui énumère les principales sources de style pour les termes techniques, l’écriture générale et l’orthographe. Les écarts que vous souhaitez faire par rapport à ces lignes directrices et une liste de toute terminologie spécifique à un domaine. Les sources de style que je recommande sont toutes disponibles en ligne:

J’ai utilisé le “Chicago Manual of Style”, mais je trouve que son style académique convient mieux aux publications avec un long délai d’exécution, comme c’est le cas dans un environnement de développement en cascade. Pour la rédaction technique dans un environnement de développement agile, je trouve que le style journalistique de l’Associated Press convient mieux.

Lorsque je rédige pour un public international, j’utilise l’anglais international (anglais américain). Il existe de nombreuses variantes régionales, mais l’alternative la plus populaire à l’anglais international, avec une orthographe formelle cohérente, est l’anglais hibernois (terminaisons en -ise). Si vous écrivez exclusivement pour un public australien, britannique, irlandais ou néo-zélandais, vous pouvez utiliser le ”Cambridge English Dictionary”. Les autres régions acceptent généralement les documents rédigés en anglais international.

Si je pouvais remonter dans le temps et empêcher la publication d’un livre, “The Elements of Style” de Strunk & White serait un concurrent sérieux. Je ne suis pas d’accord avec Geoffrey K. Pullum pour dire qu’il est en grande partie inoffensif parce que ses disciples pensent qu’ils comprennent comment bien écrire, alors que ce n’est souvent pas le cas.

Erreurs courantes

Les développeurs ne sont pas des rédacteurs de formation. La plupart d’entre eux préfèrent écrire du code plutôt que de l’anglais. Si vous êtes un développeur et que vous écrivez, ou si vous devez éditer des documents destinés aux développeurs, vous devez faire attention aux erreurs suivantes:

  • after (pas once)
  • and so on (pas etc.)
  • article (pas post)
  • because (pas as ou since)
  • can (pas are able to/have the option to)
  • center (orthographe)
  • click (pas click on)
  • dialogue (pas dialog sauf en tant qu’élément d’interface utilisateur dans les documents destinés aux développeurs)
  • done (pas finished)
  • enable (pas allow sauf lorsqu’il s’agit de contrôle d’accès)
  • enter (pas input)
  • les points d’exclamation ( ! interdits sauf dans les vœux d’anniversaire où ils sont autorisés)
  • for example (pas e.g.)
  • for more information (commence une phrase: see pour une référence croisée, refer to pour un lien externe)
  • fulfillment (orthographe)
  • help (pas facilitate: éviter les latinates)
  • IDs (capitalization)
  • is/are (pas will be: voix passive)
  • list (pas dropdown)
  • organization (orthographe)
  • please (interdit)
  • proper (interdit sauf pour décrire les noms - mot le plus galvaudé en anglais)
  • set up (action)
  • the following (interdit – toujours redondant)
  • that is (pas i.e.)
  • that/which (clauses contractuelles/expansives)
  • to (pas in order to)
  • URL (capitalisation)
  • use (pas usage)
  • use (pas utilize: éviter les latinates)
  • user’s (apostrophe)
  • using (pas via)
  • want (pas wish/would like)
  • you should (pas it is recommended to)

Mon raisonnement est le suivant:

  • Les lecteurs peuvent ne pas avoir l’anglais comme première langue:
    • Évitez l’ambiguïté temporelle.
    • N’utilisez pas d’abréviations latines (toutes les langues ne sont pas d’origine latine).
    • N’utilisez pas de latin (utiliser, faciliter, etc.).
    • N’utilisez pas de mots pour signifier plus d’une chose (une fois ne devrait signifier qu’une seule fois).
  • Utilisez exclusivement l’anglais américain. J’ai vu un mélange d’anglais britannique et américain dans des noms de variables de code, avec des résultats prévisibles.
  • Utilisez la voix active lorsque c’est possible, mais pas lorsque la voix passive semble plus naturelle quand vous la lisez à haute voix.
  • Quand il s’agit de majuscules, les développeurs écrivent instinctivement en CamelCase.
  • Les lecteurs considèrent toute tâche commençant par please comme optionnelle.
  • Évitez les mots que la traduction automatique traduit souvent de manière erronée.

Préférences de style

Il y a des domaines que le guide de style en ligne de Microsoft ne couvre pas. Il y a aussi des cas où je m’écarte des conseils de Microsoft.

Actions

Une erreur courante consiste à placer l’action avant la raison. Écrivez “pour réaliser X, faites Y”, et non “faites Y pour réaliser X”.

Admonitions

Je préfère m’en tenir à ces quatre admonestations:

  • Avertissement: Risque de blessure, de violation de la sécurité ou de perte de données.
  • Caution: Quelque chose qui peut empêcher l’accomplissement d’une action prévue.
  • Note: Quelque chose de suffisamment important dans le texte pour mériter qu’on y prête attention.
  • Conseil: Conseil que le lecteur peut ignorer en toute sécurité: Conseil que le lecteur peut ignorer en toute sécurité.

Ils ne doivent contenir que du texte. Ils ne doivent pas figurer dans les tableaux. Et n’en mettez pas deux ou plus l’un à côté de l’autre.

Contractions

Microsoft recommande l’utilisation de contractions (don’t, it’s, etc.), sauf lorsqu’il s’agit d’accentuer une phrase négative (do not). Elles contribuent à créer un style de communication plus informel, c’est pourquoi je les utilise dans ce blog. Mais je les éviterais dans toute communication d’entreprise en raison du risque d’abus. Mais si vous les utilisez, “it’s not” contient une syllabe de moins que “it isn’t”.

Feedback

Dans les textes en ligne, prévoyez des boutons “pouce en l’air” et “pouce en bas” liés à votre fournisseur d’outils d’analyse.

Images

Utilisez-les avec parcimonie. Recadrez-les aussi étroitement que possible.

Magie

Évitez les termes fantastiques dans la documentation technique (apparaît, souhait, sorcier, etc.).

La navigation dans l’interface utilisateur doit faire l’objet d’une rubrique spécifique. Vous pouvez y faire référence, mais ne la répétez pas. N’utilisez pas de crochets à angle droit (les éléments de l’interface utilisateur sont souvent déplacés).

Éléments de l’interface utilisateur

Utilisez le nom de l’élément d’interface utilisateur tel qu’il apparaît. Si le nom est manquant ou problématique, insistez pour que l’ingénierie le modifie.

Souligner

Le soulignement est une survivance des machines à écrire. Ne l’utilisez pas.

Écrire pour un public mondial diversifié

Ce sujet fait l’objet d’un article à part entière.