Comment choisir un sujet d'article à partir des besoins réels des utilisateurs

Partez de la tâche du lecteur, pas du nom du sujet

Rédigez la proposition de besoin en trois parties :

En tant que [lecteur spécifique], j'ai besoin de [faire ou décider quelque chose], afin de pouvoir [obtenir un résultat utile].

Cette structure est adaptée de la méthode des besoins utilisateurs de GOV.UK, qui recommande d'identifier l'utilisateur, l'action et la raison de cette action. Ses directives incitent également les rédacteurs à la prudence quant aux verbes vagues comme « comprendre », à moins que la compréhension ne soit nécessaire pour une tâche définie (GOV.UK: Identify user needs).

Par exemple, la « photographie pour débutant » est un sujet, pas encore une tâche d'article. De meilleures options pourraient être :

La seconde version est plus précise car elle nomme un public, une action et une décision. Elle vous donne également un critère pour délimiter le périmètre : toute information qui n'aide pas le lecteur à prendre cette décision a probablement sa place ailleurs.

Conservez une seule intention principale par article. Une question demandant comment choisir un outil, une question demandant comment utiliser cet outil et une question demandant si l'outil est adapté peuvent être liées, mais elles peuvent nécessiter des prérequis et des résultats différents. Les regrouper trop tôt produit une page au titre très large, mais incomplète pour chaque tâche.

Recueillez des preuves dans un registre de preuves

Une question est une piste, pas automatiquement un sujet. Consignez suffisamment de contexte pour juger si elle correspond à un besoin d'information public. Une simple feuille de calcul suffit ; GOV.UK recommande d'ailleurs d'enregistrer les éléments de preuve aux côtés des besoins utilisateurs et des critères d'acceptation (GOV.UK: Identify user needs).

Utilisez une ligne par question observée ou par groupe de questions étroitement liées :

Ne gonflez pas la fréquence en comptant la même question copiée sur plusieurs canaux. Enregistrez le besoin sous-jacent une seule fois et notez les canaux où il est apparu. Inversement, ne rejetez pas un besoin simplement parce qu'il n'est apparu que quelques fois si chaque exemple montre la même tâche non résolue et que la réponse pourrait servir un public plus large.

Un registre utile distingue les faits de l'interprétation. « Quatre lecteurs ont demandé si un premier exercice nécessite un équipement spécial » est un fait. « Les lecteurs veulent un guide pour débutants à faible coût » est une interprétation. Conservez les deux, mais étiquetez-les séparément.

Séparer les besoins publics des questions relevant uniquement du support

La question éditoriale clé n'est pas simplement : « Quelqu'un a-t-il posé cette question ? » C'est plutôt : « Une page générale peut-elle aider un groupe significatif de lecteurs à accomplir la même tâche ? » Le guide de langage clair de Digital.gov part du constat que les gens visitent les sites web pour faire différentes choses et recommande d'organiser le contenu autour du public et de ce qu'il doit accomplir (Digital.gov : Principes du langage clair).

Classez chaque candidat dans le registre :

Un besoin public récurrent :

Créez ou mettez à jour un article lorsque la question a une réponse stable et générale et que la même tâche apparaît chez différentes personnes, sur différents canaux ou dans différentes situations. Les exemples incluent le choix entre des options clairement décrites, la préparation à un processus courant ou le diagnostic d'un problème largement observable. L'article doit préciser son public cible et ses limites afin que les lecteurs puissent déterminer s'il s'applique à eux.

Un besoin relevant uniquement du support :

Une question relevant uniquement de l'assistance dépend de données de compte privées, d'une commande individuelle, d'une configuration personnelle ou d'une action que seul un opérateur peut effectuer. Elle peut justifier une consigne d'assistance ou un canal de contact, mais pas nécessairement un article éditorial général. Ne transformez pas « Pourquoi mon compte a-t-il reçu ce message ? » en une explication universelle lorsque la réponse dépend d'informations inaccessibles aux autres lecteurs.

Vous pouvez tout de même publier une page d'accompagnement publique s'il existe une tâche générale et reproductible, comme expliquer la signification de la catégorie de message et les informations qu'un lecteur doit rassembler avant de contacter l'assistance. Gardez la résolution privée en dehors de l'article.

Un besoin dupliqué :

Un doublon est une véritable question à laquelle une page existante répond déjà avec le niveau de détail approprié et pour le même public. L'action appropriée peut consister à améliorer l'introduction, les exemples, la navigation ou une condition manquante de la page existante. Une nouvelle URL diviserait l'attention sans apporter de tâche distincte.

Sans un inventaire complet du site, un éditeur ne peut honnêtement déclarer qu'aucun doublon n'existe. La réponse pratique consiste à inspecter les pages pertinentes connues, à marquer la vérification de l'inventaire comme incomplète si nécessaire, et à éviter de présenter un nouvel article comme la seule réponse.

Utiliser une grille de décision avant d'attribuer un titre

Passez le candidat au crible de cinq critères. Un « non » n'élimine pas toujours l'idée ; il vous indique quel type de travail est nécessaire.

Utiliser le résultat comme un filtre éditorial :

Ce filtre est une déduction éditoriale issue de deux principes tirés des sources : le contenu doit répondre à un public et à une tâche définis, et l'éditeur doit conserver des preuves du besoin. Il s'agit d'une aide à la décision, pas d'une formule pour moteur de recherche.

Transformer le besoin retenu en un brief d'article utile

Une fois qu'un sujet a franchi l'étape de validation, rédigez le brief avant de choisir une formulation peaufinée. Incluez :

Pour l'exemple de sujet, une liste de contrôle de validation pourrait être : le lecteur est capable de convertir une question brute en une déclaration utilisateur ; d'identifier la tâche centrale ; de classer les éléments de preuve comme publics, réservés à l'assistance ou faisant doublon ; et de choisir entre créer, mettre à jour, mettre en attente ou refuser. Cela suit la logique des critères d'acceptation de GOV.UK, qui décrivent ce qui doit être vérifié pour qu'un besoin utilisateur soit satisfait (GOV.UK : Identify user needs).

Utilisez le brief pour cadrer le titre. « Comment choisir un sujet d'article à partir des besoins réels des utilisateurs » convient aux rédacteurs qui ont besoin d'une méthode de sélection reproductible. « Comment trouver les meilleurs sujets de contenu » serait plus large et impliquerait un classement non étayé ou un jugement de valeur. Les propres consignes de Google demandent si un site a un public visé, si le contenu aide les lecteurs à atteindre leur objectif et s'il est conçu pour les personnes plutôt que principalement pour attirer des visites depuis les moteurs de recherche (Google Search Central : Creating helpful, reliable, people-first content). Ces questions renforcent la valeur d'une tâche éditoriale précise, mais elles ne garantissent ni le trafic ni le classement.

Rendre l'article exploitable, lisible et facile à maintenir

Un besoin réel peut tout de même aboutir à une page médiocre si le brouillon oblige le lecteur à reconstituer la réponse. Placez la réponse directe près du début, puis expliquez les conditions qui peuvent la modifier. Utilisez la terminologie du lecteur issue du registre lorsqu'elle est claire, mais définissez les termes éditoriaux internes tels que « réservé à l'assistance » et « doublon ».

Organisez l'article autour de décisions et d'actions plutôt que d'une liste de mots-clés vaguement liés. Digital.gov recommande d'écrire pour son public, d'organiser l'information, d'utiliser un langage court et simple, et d'éviter le jargon inutile (Digital.gov : Principles of plain language). Pour une méthode éditoriale, cela signifie présenter les champs du registre, la grille de décision et au moins un exemple concret, plutôt que de simplement conseiller aux rédacteurs de « comprendre leur public ».

Avant la validation, vérifiez chaque affirmation importante :

Si la réponse à la dernière question est négative parce que l'inventaire est incomplet, consignez cette limite. Une mention honnête « nécessite un examen de l'inventaire du site » est plus utile qu'une affirmation infondée selon laquelle le sujet est inédit.

Continuer sur ce thème