Créer un guide de rédaction (pour l'anglais)
Publié le 25 août 2022 par Andrew Owen (7 minutes)
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.
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:
Mon raisonnement est le suivant:
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.
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”.
Je préfère m’en tenir à ces quatre admonestations:
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.
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”.
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.
Utilisez-les avec parcimonie. Recadrez-les aussi étroitement que possible.
É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).
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.
Le soulignement est une survivance des machines à écrire. Ne l’utilisez pas.
Ce sujet fait l’objet d’un article à part entière.