Skip to content

Guide pratique de rédaction

Mozinet edited this page Feb 28, 2021 · 1 revision

Guide pratique de rédaction (anciennement, du rédacteur) du groupe de communication de Mozilla francophone.
Travail en cours : participez en modifiant la page ou en en parlant sur Matrix.

Table of Contents

Le fond

Les sources


Les sources fiables



Les sources peu fiables à éviter


Les contenus

Les contenus déclarés acceptables


La galette des rois

Les contenus à éviter


À « Noël » préférer « les fêtes ».

Éviter de fêter des anniversaires de personnes.

La forme


L’orthographe


Les fautes d’orthographe nuisent à la crédibilité des contenus publiés. Relire et faire relire est vraiment important. Pensez à utiliser l’extension Grammalecte.

Typographie

Ne tient pas compte de la transformation automatique typographique du CMS.

Voir cette table des caractères spéciaux avec entité HTML, caractère ASCII, code clavier Windows et nom courant. Il existe des claviers à installer pour avoir les caractères spéciaux courants sous la main.

Nous n’utilisons pas les guillemets anglophones ni les guillemets droits, mais toujours les guillemets francophones « » suivi pour l’ouvrant et précédé pour le fermant d’une espace (n. f.) insécable classique (   Alt+0160).

On utilise des espaces insécables devant les ponctuations hautes (deux-points, point-virgule, point d’exclamation et point d’interrogation) ou encore avant les signes pour cent (non collés au nombre). Les symboles monétaires sont placés derrière la valeur et aussi précédés d’une espace insécable. Le symbole degré est collé au nombre qu’il suit sauf lorsque, s’agissant de température, il est lui-même suivi de l’abréviation précisant l’échelle utilisée (« 100° », mais « 100 °C »)

Pour les nombres, le séparateur des milliers doit être une espace insécable.

Lorsque trois points sont présents (points de suspension), nous utilisons le caractère ellipse « … » à la place (… … Alt+0133). Attention, l’espace est après, pas avant et veillez à ne pas utiliser « etc… » ou « ,… ».

Les tirets (à ne pas confondre avec le trait d’union plus court) sont les tirets demi-cadratins – (– – Alt+0150) pour les incises à l’intérieur d’une phrase (on peut mettre une virgule après le second tiret qui disparaît devant un point-virgule ou un point final) et cadratins — (— — Alt+0151) pour les répliques (sauf la première) dans un dialogue.

Les titres ne prennent pas les ponctuations finales point ni deux-points.

Accessibilité, lisibilité et utilisabilité

Les liens hypertextes

Il faut éviter les liens « ici » ou « cliquez ici » ou toute autre instruction générique.

Les liens avec le même texte doivent avoir la même URL.

Le soulignement est réservé aux liens.

Les liens ne doivent pas se suivre juste séparés par des espaces.

Ne pas forcer les liens à s’ouvrir dans une nouvelle fenêtre sans prévenir les utilisateurs au minimum.

Ne pas mettre de liens trop longs. Être assez long pour être compris, mais suffisamment court pour éviter la confusion.

Indiquer le poids et format de chaque document à télécharger, le nombre de pages et la durée des vidéos et fichiers audio liés (PDF, 98 Ko, 16 pages).

HTML : remplissez bien l’attribut title dont la valeur apparaît en infobulle lors du survol par le curseur de la souris mais éviter de mettre là des informations essentielles que certains agents utilisateurs ne rendent pas.

L’attribut hreflang indique la langue du contenu cible du lien avec un code code ISO 639-* en deux ou trois lettres en minuscules pour la langue. Les caractères blancs ne sont pas autorisés dans les codes de langue. Un sous-code peut être rajouté à la langue après un trait d’union sous la forme d’un nom territorial ou d’un code d’État ou de territoire ce dernier en majuscules (ex. : hreflang="fr-CA" sera pour indiquer que le document cible est en français du Canada).

L’attribut lang verra sa valeur formée de la même façon pour indiquer la langue du texte dans la balise (ex. : <i lang="la">Errare humanum est</i> ou <abbr title="Application programming interface" lang="en">API</abbr>).

Images

HTML : Les images doivent avoir un attribut alt (vide pour une image purement décorative) avec une courte description. Pour les longues descriptions, un attribut longdesc existe pour indiquer l’URL d’un fichier (texte ou HTML) avec une description exhaustive de l’image (utile pour les images avec du texte ou les infographies). Cependant, comme cet attribut est très peu pris en charge et très peu visible dans les interfaces utilisateur, il convient d’ajouter un D avec un lien vers le fichier (ex. : <a href="URL_fichier_descritpion" hreflang="fr"><abbr tite="Description">D</abbr></a>), par exemple pour les infographies.

Les tableaux

Pas de tableau de mise en forme. Les tableaux sont réservés aux données tabulaires.

Prévoir un titre pour les tableaux.

HTML : l’attribut summary de la balise table a été déclaré obsolète par le HTML5. Préférez un élément caption ou une autre méthode.

Textes

Mettre des accents sur les lettres capitales.

Appliquer un contraste suffisant entre contenus et arrière plan. Une application utile pour vérifier votre contraste est Colour Contrast Analyser. Les outils de développement de Firefox peuvent aussi aider.

Le HTML

Quelques conseils quel que soit le mode de saisie (wiki ou HTML) choisi :

En résumé : le HTML sert à structurer les données, le CSS à les habiller.

À finir

Préparer la publication des contenus


Après avoir écrit des articles sur le blog, il importe de penser aux contenus qui vont permettre de :

  1. « Pousser »/mettre en avant ces articles ;
  2. Créer des contenus pour Twitter et Facebook qui permettent de créer de la réciprocité et de l’échange avec des communautés plus larges.

Les étapes clés avant de publier un tweet ou un statut Facebook faisant la promotion d’un article du blog


Le contenu peut-il choquer une communauté ?


Il est important d’être très explicite dans les tweets et statuts Facebook. Ceci afin d’être sûr·e que le contenu ne soit pas interprété de façon incorrecte.

Plusieurs questions permettent de diminuer ce risque :

  • Y a-t-il une référence communautaire dans le contenu publié ? Si oui, cette communauté est-elle visée, contestée, dénigrée ? À éviter le plus possible le cas échéant, sauf si c’est un objectif de communication manifeste et validée par le groupe ;
  • Y a-t-il une actualité chaude qui parasite l’interprétation du contenu ? (ex. : un attentat, un « buzz », un phénomène de société, etc.). Là aussi, à proscrire.

L’orthographe est-elle correcte, la syntaxe précise ?


Rien de pire qu’un contenu « mal » écrit qui est ensuite relayé en ligne.

Les appels à l’action (calls to action) sont-ils bien implémentés ?


Vérifiez à tout prix que les liens fonctionnent, que les hashtags sont pertinents et que les personnes à mentionner le sont effectivement.

L’étape de prépublication et de validation par la communauté


L’adage « Vérité en deçà des Pyrénées, erreur au-delà » est crucial dans les réseaux sociaux. Afin d’éviter une erreur, rien de tel que demander à un regard extérieur un avis. La plupart des « bad buzz » et des erreurs de communication partent d’une bonne intention.

Une fois que votre tweet ou statut Facebook est prêt, relu, vous pouvez l’envoyer au groupe de comm. Si personne ne conteste dans l’heure qui suit, alors le contenu peut être publié. Cette double lecture n’est pas un processus inutile puisque vous aurez déjà fait un travail préparatoire avant de demander le regard extérieur.

La mise en ligne et le suivi


Le contenu une fois publié doit être suivi. En effet, la plupart des réponses ou des interactions à un tweet se passent rapidement après la mise en ligne. Il faut donc converser par la suite et s’assurer qu’on maintient le lien avec la communauté.

Par ailleurs, un tweet de promotion de contenu du blog peut très bien être répété ou légèrement modifié plusieurs fois par jour : à travailler dès cette étape-ci.

Les étapes clés avant de publier un tweet ou un statut Facebook relayant une actualité ou permettant une conversation avec la communauté (Twitter)


Au-delà des étapes précédemment évoquées pour la publication d’un statut ou tweet faisant la promotion d’un contenu du blog, de nouvelles règles ou principes doivent être ajoutés et pensés avant publication :

L’article que je relaie a-t-il une valeur pour la communauté de followers (abonnés) ?


Une petite liste permet de se faire une idée assez simplement. Au moins un « oui » permet d’avoir une bonne raison de publier un contenu :

  • est-ce divertissant pour la communauté ? Si oui, pourquoi ?
  • le contenu relayé va-t-il permettre de nourrir la personnalité de Firefox ou Mozilla en ligne ? (par ex. : le contenu permet-il de rendre plus sympathique Firefox ? ou est-ce en lien avec le logiciel ?)
  • le contenu relayé va-t-il permettre de créer des liens avec des communautés affinitaires avec lesquelles nous n’avons pas encore suffisamment de liens ?
  • le contenu relayé permet-il de faire notre propre promotion ?
  • le contenu relayé permet-il de mettre en lumière des grandes causes qui sont associées à la communauté Mozilla ?

Comment faire du tweet ou du retweet un contenu vraiment Mozilla


Le rôle de curation est déjà bien fait par une myriade de médias, utilisateurs Twitter, etc. Au-delà du relai d’articles (qui en soi est tout à fait légitime), y a-t-il une possibilité de rajouter un peu de Mozilla dans le tweet ?

  • A-t-on déjà écrit un article sur la thématique du contenu poussé ? Si oui, pourquoi ne pas le mentionner (ex. : « article du Monde sur les risques de surveillance des internautes français URL », Mozilla avait interrogé la communauté sur le sujet ici (URL2) ;
  • Peut-on faire un petit commentaire autour du contenu relayé (ex. : si le contenu est « LOL », pourquoi ne pas ajouter des « Le FOX en rigole encore : URL », « Approuvé par le fox… », etc.

Parcours typique du rédacteur (pas à pas)


  1. rédiger un premier jet en HTML ou au format wiki de Dotclear
  2. choisir des illustrations (en notant l’origine, l’auteur et la licence de réutilisation)
  3. faire une copie d’un modèle de document partagé (Gdoc) ou de pad selon le genre d’article
  4. remplir le document avec y compris :
    1. le titre affiché au-dessus de l’article
    2. le titre SEO, title de la page web pour améliorer le référencement sur les moteurs de recherche
    3. les tags ou mots-clés aussi pour améliorer le référencement
    4. un call to action ou incitation à faire réagir la communauté
    5. la/les signature(s) du/des auteur(s) ou autrice(s)
    6. un lien vers l’article précédent dans la catégorie
    7. le crédit et les éventuelles licences pour les illustrations (internes et externes)
    8. une éventuelle licence pour le texte si elle s’avère dérogatoire de celle par défaut de notre site
  5. donner des droits de modification du document à toute personne avec le lien
  6. ajouter l’URL du document de travail sur la carte Trello de l’article et y ajouter le label « Relecture demandée » ; ajouter une checklist « Reste à faire »
  7. mettre à relire sur la liste avec l’URL de partage du document de travail
  8. incorporer les retours en tenant compte des commentaires et en acceptant ou refusant les suggestions de modifications
  9. mettre sur le blog avec les illustrations ou demander aux membres avec des droits sur le blog d’y mettre son article (sans oublier de joindre les illustrations)
  10. programmer ou publier le billet de blog
  11. ajouter la future URL ou l’URL du billet sur la carte Trello avec l’heure de publication
  12. indiquer la publication ou l’heure de publication avec l’URL sur notre liste
  13. faites la promotion de votre œuvre sur vos propres réseaux sociaux :-)
Guide pratique du rédacteur commencé par le groupe de communication pour feu Firefox OS.
Clone this wiki locally