Rédacteur UX

Je commence par identifier ce que l'utilisateur ressent réellement à cet instant, le plus souvent de la frustration ou de l'incertitude, et j'écris pour cette émotion plutôt que pour la logique interne du système. Pour un message d'erreur, je cherche trois choses en un minimum de mots : ce qui s'est passé, pourquoi cela compte pour l'utilisateur, et ce qu'il faut faire ensuite. J'évite de rejeter la faute sur l'utilisateur ou de me cacher derrière un code technique du type 'Erreur 403', sauf si le support en a vraiment besoin, auquel cas je le place dans un lien de détails plutôt que dans le titre. Pour les états vides, je vois ce moment comme une invitation plutôt qu'une impasse : au lieu d'écrire 'Aucun résultat', je propose une prochaine étape concrète, comme ajuster un filtre ou ajouter un premier élément. Je relis toujours le texte à voix haute avant de le livrer, parce qu'une phrase qui semble correcte sur une maquette Figma sonne souvent de façon mécanique une fois prononcée, et c'est en général le signe qu'il faut la retravailler.

Je considère le guide de ton comme une contrainte qui accélère le travail, pas comme un carcan. Avant d'écrire quoi que ce soit de nouveau, je vérifie si un modèle existe déjà pour la situation, car la cohérence compte plus pour l'utilisateur qu'une nouvelle formule originale à chaque écran. Quand une consigne ne correspond vraiment pas à un nouveau cas d'usage, je ne l'ignore pas silencieusement : je signale le manque à la personne responsable du système de contenu et je propose un ajout, exemples à l'appui, pour que la prochaine personne qui rédige n'ait pas à résoudre le même problème. J'ai aussi dû faire l'inverse, quand une consigne écrite pour le ton marketing s'était retrouvée copiée dans des écrans produit où elle sonnait trop légère pour un avertissement de suppression de données. Travailler avec un design system, c'est aussi construire des textes en composants réutilisables quand c'est pertinent, des gabarits avec variables plutôt que des phrases isolées, pour que l'équipe technique puisse les implémenter de façon cohérente sans revenir vers moi à chaque occurrence.

La concision est un moyen, pas un objectif, donc je ne coupe jamais un mot juste pour respecter une limite de caractères si cela nuit à la compréhension. Ma méthode consiste à écrire d'abord la version la plus claire, puis à repérer les mots qui ne servent à rien : les tournures hésitantes, les répétitions, tout ce que l'interface communique déjà visuellement. Un bouton placé à côté d'une icône de corbeille n'a pas besoin de dire 'Supprimer définitivement cet élément', 'Supprimer' suffit, parce que l'icône et le contexte portent déjà le sens. Là où je ne cède pas, c'est sur l'ambiguïté : si raccourcir 'Votre session expire dans 5 minutes' en 'Session expirant' fait gagner de la place mais laisse l'utilisateur incertain sur l'urgence de sauvegarder son travail, je garde la version longue. Les contraintes d'espace sur mobile rendent cet arbitrage plus difficile, donc j'écris généralement une version complète et une version raccourcie en parallèle, et je teste laquelle des deux permet toujours d'agir correctement sans relire deux fois.

J'écris chaque texte en partant du principe qu'il sera lu par un lecteur d'écran et traduit dans une langue à la structure de phrase très différente, car ces deux réalités concernent une part importante des utilisateurs. Cela veut dire éviter les formulations qui reposent sur une position visuelle, comme 'cliquez sur le bouton à droite', puisqu'une personne utilisant un lecteur d'écran n'a aucune notion de mise en page, et privilégier des libellés qui décrivent l'action plutôt qu'un texte de lien décoratif comme 'cliquez ici'. Pour la traduction, j'évite les expressions idiomatiques et les jeux de mots qui ne survivent pas au passage d'une langue à l'autre, je garde une structure de phrase simple pour que l'ordre des mots ne casse pas le sens, et je ne construis jamais une phrase en assemblant des fragments autour d'une variable, car les règles de genre et de pluriel diffèrent trop d'une langue à l'autre pour qu'une phrase découpée en anglais reste correcte en français ou en espagnol. Je signale aussi tôt les limites de caractères aux traducteurs, parce qu'un mot qui tient en anglais prend souvent 30 % de place en plus en allemand ou en français.

Nous avions une étape d'onboarding qui demandait de 'Confirmer votre espace de travail', et pendant les tests, trois participants sur cinq se sont arrêtés pour demander ce qu'était un espace de travail, un terme qu'on n'avait introduit nulle part avant dans le parcours. J'avais supposé que le mot se comprenait tout seul parce que l'équipe produit l'utilisait sans arrêt en interne, ce qui est exactement le piège : j'écrivais depuis le vocabulaire du produit et non depuis celui de l'utilisateur. J'ai réécrit l'étape pour expliquer le concept en langage simple d'abord, quelque chose comme 'C'est ici que vivront les projets de votre équipe. Ça vous convient ?', puis j'ai relancé un test rapide avec cinq nouveaux participants. Les cinq ont compris immédiatement et sont passés à l'étape suivante sans hésiter. Le changement le plus important est venu après : j'ai ajouté une règle à notre guide de style, tout nom propre au produit doit avoir une définition en langage simple la première fois qu'il apparaît dans un parcours visible par l'utilisateur, pas seulement dans la documentation.

Un développeur voulait livrer 'Entrée invalide' comme message d'erreur pour un champ de numéro de téléphone, parce que ça correspondait à la sortie par défaut d'une librairie de validation et ne demandait aucun travail supplémentaire. J'ai contesté ce choix parce que ça ne dit pas à l'utilisateur ce qui cloche réellement : un indicatif manquant, des caractères en trop ou une simple faute de frappe demandent des corrections très différentes, et un message générique laisse chacun deviner. Plutôt que de débattre sur le ton, j'ai demandé quels cas de validation précis la librairie distinguait déjà en interne, et il s'est avéré que trois états d'erreur distincts existaient sous le capot mais étaient tous réunis dans un seul message. J'ai écrit trois remplacements courts et précis, et j'ai montré au développeur que le coût d'implémentation supplémentaire tournait autour de vingt minutes puisque la logique existait déjà, elle n'était juste pas exposée. Ce recadrage, passer de 'ma préférence de rédaction' à 'voici le volume de tickets support que ça génère', a permis de le faire livrer. Le mois suivant, on a observé une baisse des tickets support liés à ce champ.

À mon arrivée, les décisions de ton vivaient dans la tête de chaque rédacteur et dans des fils Slack éparpillés, si bien que chaque nouvelle fonctionnalité réinventait des règles qui existaient déjà quelque part. J'ai commencé le guide par les cas les plus fréquents de friction : la rédaction des états d'erreur, la façon de nommer le produit lui-même, les règles de majuscules, et le traitement des nombres et des dates, plutôt que de vouloir tout documenter d'un coup. Je l'ai construit comme une référence vivante directement dans notre outil de design system, à côté des composants concernés, pour qu'une personne posant un composant bouton voie la règle de texte juste là plutôt que d'aller chercher sur un wiki séparé. J'ai aussi mis en place une étape de revue légère : tout nouveau schéma apparu deux fois dans un sprint devenait une proposition d'ajout au guide plutôt qu'une décision isolée. Six mois après, de nouveaux rédacteurs et même des personnes hors de l'équipe rédaction s'y référaient spontanément en rédigeant leurs propres textes, ce qui était le vrai signe que le guide était devenu utile plutôt que décoratif.

Je commence par m'assurer que le test porte réellement sur une seule variable, car il est facile de changer accidentellement le ton, la longueur et le verbe d'action en même temps, et de ne plus savoir ensuite quel changement a produit le résultat. Pour un test récent sur un parcours de résiliation d'abonnement, on a isolé uniquement le cadrage de l'offre de rétention, en gardant le texte du bouton et la mise en page identiques, et on a laissé tourner le test jusqu'à atteindre la taille d'échantillon calculée par l'équipe data pour la significativité statistique, sans regarder les résultats trop tôt. La variante qui nommait un bénéfice précis que l'utilisateur allait perdre a surpassé un 'Êtes-vous sûr ?' générique avec un écart net, mais j'ai aussi vérifié l'indicateur en aval, à savoir si les utilisateurs restés grâce à ce message continuaient réellement à utiliser le produit un mois plus tard, parce qu'une astuce de rédaction qui ne fait que retarder le désabonnement n'est pas une vraie victoire. Ce qui compte pour moi, c'est l'indicateur qui survit au-delà du clic immédiat, pas seulement le résultat du test en lui-même.

J'essaie d'entrer dans un projet avant que les maquettes ne soient figées, parce qu'un texte écrit après que la mise en page est verrouillée se bat pour un espace qu'on ne lui a jamais réservé. Avec les designers, j'esquisse un contenu approximatif à côté de leurs premiers parcours pour qu'on résolve ensemble le nombre de mots et la hiérarchie de l'information, plutôt que d'ajuster des phrases dans des cases après coup. Avec les chercheurs, j'assiste moi-même aux sessions de test utilisateur plutôt que de me contenter du rapport de synthèse, parce que le ton et l'hésitation sur un choix de mot précis se lissent souvent dans un résumé écrit mais deviennent évidents quand on regarde quelqu'un lire un écran à voix haute. Je demande aussi aux chercheurs d'inclure quelques questions de compréhension dans leurs scripts de test, comme demander à une personne d'expliquer avec ses propres mots ce qu'un écran vient de lui dire, parce que ça révèle des textes confus qu'un simple test de complétion de tâche ne capterait jamais.

Le vrai rôle de ce texte est de rendre la conséquence concrète et précise, car un ton effrayant à lui seul ne dit rien de ce qui est vraiment en jeu. 'Cette action est irréversible' est vrai mais oubliable, donc je nommerais exactement ce qui disparaît : projets enregistrés, historique de facturation, accès de l'équipe, selon ce qui s'applique réellement, pour que la décision se prenne sur des enjeux réels plutôt que sur un avertissement vague déjà vu cent fois sur d'autres produits. J'ajusterais aussi le niveau de friction de la confirmation à la gravité de l'action : un simple bouton de confirmation suffit pour supprimer un brouillon, mais pour quelque chose d'aussi définitif que la suppression d'un compte, je demanderais de taper le nom du compte ou une phrase de confirmation, à la fois pour ralentir un clic impulsif et pour éviter un double-clic accidentel. Je garderais aussi le libellé du bouton précis, 'Supprimer le compte' plutôt qu'un 'Confirmer' générique, parce que dans un moment à enjeu élevé, l'ambiguïté est la dernière chose à laisser entre l'utilisateur et une action qu'il ne pourra pas annuler.