wvvb/rédaction-site-web

Rédaction pour site web

Un site doit permettre à la bonne personne de reconnaître sa situation, de comprendre ce que le produit fait et de savoir quoi faire ensuite.

Principe : Écrire à partir de la réalité du visiteur, pas de la liste de fonctionnalités du produit. Le texte doit donner l'impression d'une personne qui comprend le travail, pas d'un marketeur qui explique comment fonctionne le marketing.

Ceci est une compétence d'écriture et de conception d'information, pas un détecteur d'IA ni une formule de conversion rigide. Ne pas optimiser pour sembler « humain » au détriment de la vérité, de l'accessibilité ou de la précision.

Étiquettes des preuves

Version 1.1. Les étiquettes n'apparaissent que sur les affirmations d'efficacité : des déclarations selon lesquelles quelque chose améliore la reconnaissance, la compréhension, la confiance ou la conversion. Les obligations et les étapes de workflow ne sont pas notées.

• [E] preuve directe vérifiée : étude évaluée par les pairs ou test documenté mesurant l'effet déclaré, avec taille d'effet et limites.
• [P] pratique plausible : utile sans preuve mesurée directe pour ce public.
• [S] préférence de style éditorial. Les éléments de style sont notés dans references/evidence.md ; ils ne sont pas marqués en ligne dans cette compétence.

Aucune règle de cette compétence n'est [E] pour la conversion d'une page d'atterrissage. Traitez les conseils de conversion comme une hypothèse à tester sur le site réel, et ne promettez jamais d'augmentation sans mesure. Les affirmations d'efficacité non étiquetées ici sont des pratiques consultatives à [P] ; les obligations et les étapes de workflow ne sont pas notées. La classification complète par élément, les sources et les expériences candidates se trouvent dans references/evidence.md.

Règles non-négociables

1. Attirer par la pertinence. Nommer un problème, une tâche ou un résultat spécifique que le visiteur ciblé reconnaît. Présenter rapidement le produit pour que le visiteur comprenne ce qui est proposé. [P]
2. Expliquer le lien de causalité. Montrer ce que le produit fait réellement pour aider. Ne pas remplacer les mécanismes par des promesses. [P]
3. Sembler naturel. Privilégier le langage courant, les noms concrets et les verbes ordinaires. Maintenir la précision technique pour les publics techniques.
4. Ne pas utiliser de tirets cadratin ou demi-cadratin dans les textes proposés pour le site. Les remplacer par un point, une virgule, deux-points ou une reformulation naturelle. Conserver la ponctuation d'origine lors de la citation de sources. Si l'utilisateur demande explicitement un style différent, le suivre.
5. Pas d'émotions fabriquées. N'inventer ni douleur, ni urgence, ni peur, ni statistiques, ni preuve sociale, ni résultats, ni fonctionnalités.
6. Pas de modèle obligatoire. Ne pas donner à chaque site la même séquence Problème / Agitation / Solution / Fonctionnalités / Témoignages / CTA. Choisir les sections en fonction de ce dont les visiteurs ont besoin pour décider.
7. Ne pas réécrire simplement pour réécrire. Si l'original est plus clair, le conserver. Faire le plus petit changement qui améliore la compréhension.

Déterminer ce que le visiteur doit comprendre

Avant d'éditer, examiner le matériel fourni par l'utilisateur : page live, capture d'écran, texte actuel, brief ou code source. Déterminer :

• Public : Qui en a besoin ? Utiliser un rôle ou une situation reconnaissable plutôt que « tout le monde ».
• Déclencheur : Quel événement les pousse à chercher de l'aide maintenant ?
• Tâche : Qu'essaient-ils d'accomplir ?
• Obstacle : Pourquoi l'approche actuelle échoue-t-elle ou demande-t-elle trop d'efforts ?
• Coût : Que signifie réellement cet obstacle pour eux ? Temps perdu, questions sans réponse, confusion, risque ou argent. N'inclure que les conséquences étayées par le contexte.
• Changement souhaité : Qu'est-ce qui améliorerait leur prochaine heure, journée ou workflow ?
• Mécanisme du produit : Comment le produit provoque-t-il ce changement, en termes concrets ?
• Preuve : Qu'est-ce qui est démontré, documenté ou vérifié ?
• Action : Que peuvent-ils cliquer, essayer, demander ou lire ensuite ?

Garder une distinction nette entre faits et hypothèses. Si des détails manquent, utiliser un langage prudent et étiqueter les hypothèses matérielles dans votre explication à l'utilisateur. Ne pas inventer de clients ou de workflows spécifiques.

Construire un modèle de problème interne

Utiliser ceci comme aide au raisonnement, jamais comme texte à publier :

Quelqu'un dans [situation réelle] essaie de [tâche], mais [obstacle]. Il/elle veut [résultat]. Le produit aide en [mécanisme spécifique].

Puis le réduire à un moment reconnaissable. Le moment est plus important qu'une catégorie abstraite.

• Abstrait : « Les équipes financières ont besoin de workflows de rapprochement simplifiés. »
• Concret : « Le total des paiements et vos enregistrements de transactions ne correspondent pas. »
• Abstrait : « Améliorer l'observabilité dans les déploiements distribués. »
• Concret : « Un déploiement a échoué. Vous cherchez l'erreur dans trois services. »

Un bon titre peut commencer par le problème ou par le résultat souhaité. Choisir ce qui indique le plus rapidement au visiteur ciblé : « C'est pour moi. » Un titre axé sur le problème n'est pas automatiquement le meilleur si le public sait déjà exactement ce qu'il veut.

Composer le message

Réfléchir à ces moments en interne. Ne pas les imprimer comme six sections de site identiques.

1. Reconnaissance : Une situation réelle que le visiteur a vécue ou peut imaginer.
2. Signification : Ce qui reste non résolu, difficile, coûteux ou incertain. Une conséquence spécifique suffit généralement.
3. Soulagement : Ce qui devient possible ou plus simple.
4. Mécanisme : Comment le produit y amène le visiteur.
5. Crédibilité : Un exemple réel, une démo, une capacité, une limitation ou une source qui inspire confiance.
6. Action suivante : Un CTA dont la destination tient sa promesse.

Le premier écran doit généralement apporter la reconnaissance, la solution et un mécanisme crédible sans que le visiteur ait besoin de défiler. Ne pas passer la moitié d'une page à dramatiser un problème que le visiteur comprend déjà.

Écrire le héros

• Titre : Une pensée claire sur la tâche, le problème ou le résultat souhaité du visiteur. La spécificité l'emporte sur l'esprit.
• Soutien : Nommer à qui cela s'adresse et décrire comment cela fonctionne en une ou deux phrases naturelles. Supprimer tous les mots qui ne changent pas la compréhension du lecteur.
• CTA : Une action réelle comme « Voir un exemple », « Lire la doc », « Essayer la démo » ou « Parler au responsable », uniquement si cette action existe.
• Visuel : S'il est présent ou demandé, préférer un workflow réel, un état d'interface ou un exemple de données avant-après plutôt que des métaphores décoratives abstraites.

Le titre et le soutien doivent faire des jobs différents. Ne pas dire la même promesse trois fois avec des mots différents.

Expliquer la solution comme une cause, pas un slogan

Pour chaque fonctionnalité importante, raisonner par :

Ce qu'elle fait -> ce qui change pour le visiteur -> pourquoi cela importe -> ce qui étaye l'affirmation.

Exemple :

• Capacité : Exécuter du SQL généré sur des fichiers Parquet, JSON et CSV sur l'infrastructure du client.
• Ce qui change : Le client peut enquêter sur ces fichiers sans envoyer leur contenu à un fournisseur d'analyse hébergé.
• Signification : Leurs données restent dans l'infrastructure qu'ils exploitent.
• Portée : Cela ne prouve pas que l'ensemble du système est exempt de risques de sécurité.

Utiliser la partie la plus pertinente de cette chaîne dans le héros. Mettre le reste dans une démo, une section de workflow, une FAQ ou de la documentation selon les besoins.

Rendre le texte comme écrit par un humain

Un texte à son humaine est souvent plus spécifique, moins symétrique et moins impatient de s'expliquer. Il semble édité, pas généré d'un seul coup.

Privilégier

• Une situation concrète plutôt qu'une étiquette de catégorie.
• Un vocabulaire familier plutôt qu'un jargon conceptuel.
• Des détails qui n'ont de sens que pour ce public et ce produit.
• Des descriptions directes plutôt qu'un enthousiasme vide.
• Des rythmes de phrases différents quand ils aident le lecteur à suivre une idée.
• Un exemple utile qui clarifie l'affirmation.
• Des limites honnêtes, des compromis pratiques et des termes techniques précis quand ils construisent la confiance.
• Des transitions naturelles qui suivent l'idée réelle, pas des phrases de liaison préfabriquées.

Supprimer ou reformuler

• Remplissage marketing : « Débloquer », « booster », « sans couture », « de pointe », « révolutionnaire », « nouvelle génération », « révolutionner », « autonomiser » et termes similaires quand ils remplacent le sens.
• Faux contrastes : « Ce n'est pas juste X. C'est Y. », « Arrêtez de faire X. Commencez à faire Y. », « Le futur de X est là. » N'utiliser le contraste que lorsqu'il explique une différence réelle, en langage normal.
• Structure annoncée : « Dans cette section, nous allons explorer... », « Allons-y. », « Voici pourquoi c'est important. » Ne pas dire aux visiteurs que vous allez expliquer quelque chose ; expliquez-le.
• Répétition : Un titre, un sous-titre, trois fiches fonctionnalités et un paragraphe de conclusion qui font tous la même affirmation.
• Sections parfaitement symétriques : Trois cartes avec des motifs grammaticaux identiques, des comptes de mots identiques et un résumé soigné juste pour compléter la mise en page.
• Sens surexpliqué : « Cela permet aux entreprises de prendre le contrôle de leur succès. » Si la conséquence est évidente, arrêtez d'écrire.
• Langage émotionnel vide : « Dites adieu aux maux de tête » ou « Ne vous inquiétez plus jamais » sans raison concrète.
• Astuces conversationnelles forcées : Questions rhétoriques répétées, anecdotes fictives, humour forcé, contractions excessives et vulnérabilité artificielle.
• Polissage syntaxique qui semble contre nature : Syntagmes nominaux denses, chaînes d'adjectifs et ponctuation faisant le travail de phrases claires.

Ne pas faire d'une liste noire de mots votre stratégie d'édition. Un mot peut être approprié dans le bon contexte. L'exigence de ponctuation ci-dessus est une règle de style de projet ; la tâche plus profonde est de corriger la pensée, la structure et les preuves. Un rédacteur qui se contente de supprimer les tirets et de remplacer « tirer parti » par « utiliser » n'a pas résolu le problème.

Éditer à deux niveaux

Passe structurelle :

• Le vrai problème du lecteur est-il visible, ou la page parle-t-elle d'elle-même ?
• Chaque section apporte-t-elle quelque chose de nouveau ou lève-t-elle une véritable objection ?
• Le produit apparaît-il avant que le visiteur ne perde tout intérêt ?
• L'argumentaire est-il linéaire uniquement parce que le modèle a utilisé un template par défaut ?
• Y a-t-il des résumés inutiles, des étiquettes de scène répétitives ou des récits exagérés de l'ancien contre le nouveau ?
• Le contenu suit-il la façon dont ce visiteur particulier décide, plutôt qu'un entonnoir de vente générique ?

Passe phrastique :

• Est-ce qu'une personne compétente dirait réellement cette phrase à une autre personne ?
• Y a-t-il un nom ou un verbe plus spécifique ?
• La phrase peut-elle être coupée sans supprimer un fait ?
• La phrase essaie-t-elle d'impressionner plutôt que d'expliquer quelque chose ?
• Les faits sont-ils exacts et les avantages soutenables ?
• Y a-t-il des tirets cadratin ou demi-cadratin dans le texte proposé ? Les supprimer.

Lire le résultat en tant que visiteur, pas en tant qu'écrivain. Si cela ressemble à un discours répété, simplifier la réflexion plutôt que d'ajouter plus d'astuces « humanisantes ».

Utiliser la psychologie de manière responsable

Utiliser des principes psychologiques utiles comme des lentilles de diagnostic, pas comme des excuses pour manipuler les gens. Chaque principe ci-dessous est [P].

• Reconnaissance : Les gens s'engagent quand ils peuvent identifier la situation décrite. [P]
• Aisance cognitive : Un langage concret et un chemin cohérent réduisent l'effort. [P]
• Odeur d'information : Les titres et les CTA doivent prédire avec précision ce qui suit. [P]
• Contrôle : Les gens veulent savoir ce qu'ils peuvent inspecter, modifier, conserver ou annuler. [P]
• Confiance : Les preuves, les mécanismes réels et les limites reconnues peuvent être plus utiles que des affirmations grandioses. [P]
• Motivation : Le texte doit se connecter à quelque chose que le visiteur veut accomplir, non inventer de l'insécurité ou de la pression. [P]

Éviter la rareté factice, la preuve sociale inventée, les économies de coûts imaginées, les comparaisons de performances non fondées, les options par défaut manipulatoires ou les garanties implicites.

L'architecture de la page est contextuelle

Ne pas produire la même page d'atterrissage pour un CLI développeur, un produit d'opérations financières et un utilitaire grand public.

Pour un public expert ou développeur : Mener généralement par la tâche pratique ou le résultat technique. Montrer une commande, une interface, un exemple, un détail d'architecture ou un lien vers la documentation tôt. Éviter de surexpliquer un problème familier.

Pour les acheteurs opérationnels : Mener par un incident ou une responsabilité reconnaissable. Expliquer ce qu'ils peuvent étudier, prévenir ou accomplir, puis montrer le workflow et les contraintes.

Pour les catégories inconnues : Définir le produit tôt, l'ancrer dans une situation connue et montrer comment quelqu'un l'utiliserait réellement. La nouveauté seule n'est pas une proposition de valeur.

Pour une page à fonctionnalité unique ou déjà claire : Faire un changement précis. Ne pas ajouter une longue histoire de problème.

Chaque section doit gagner sa place en répondant à une vraie question ou objection. Si ce n'est pas le cas, la supprimer.

Exemple : Queryance

Version faible, axée sur les fonctionnalités

Analytique open source pour les opérations financières. Convertir le langage naturel en SQL et l'exécuter sur des fichiers Parquet, JSON et CSV sur votre infrastructure.

Ceci décrit d'abord la mécanique. Cela oblige les visiteurs à trouver eux-mêmes la raison de s'y intéresser.

Version Problème Humain

Découvrez pourquoi vos chiffres de paiement ne correspondent pas.

Queryance aide les équipes financières SaaS à enquêter sur les différences entre leurs enregistrements. Posez une question, révisez le SQL et exécutez-le sur des fichiers Parquet, JSON ou CSV sur votre propre infrastructure.

CTA : Parler au responsable

La première phrase nomme une tâche réelle. La seconde explique à qui s'adresse le produit et comment il fonctionne. Le CTA n'est approprié que s'il existe réellement un moyen de contacter le responsable.

Une version qui en fait trop

Encore noyé dans le chaos financier ?

Arrêtez de perdre du temps avec des tableurs obsolètes. Débloquez un rapprochement sans effort avec la nouvelle génération d'opérations financières intelligentes.

Ceci invente de l'émotion, s'appuie sur des clichés du secteur et n'explique jamais le mécanisme. C'est plus court que la bonne version mais moins informatif.

Ces exemples sont des points de départ, pas des modèles imposés. Si des clients réels utilisent un langage différent, privilégier leur langage après avoir vérifié ce qu'ils veulent dire.

Modes d'exécution

Suivre la portée de la demande de l'utilisateur.

Audit

Fournir les 3 à 5 principaux problèmes de contenu ou de hiérarchie. Citer le texte concerné, décrire ce qu'un visiteur comprendrait mal ou manquerait, et recommander des correctifs ciblés. Identifier ce qui fonctionne déjà. Ne pas revendiquer d'améliorations de conversion sans mesure.

Réécriture

Fournir un texte prêt à publier pour les sections demandées, en utilisant la voix de marque existante du site

…

[truncated for translation]