#27 – La rédaction technique : une information utile et minimaliste

Saison 2 du podcast Le Brief, c’est (enfin) parti !

Pour ce tout premier épisode de la saison 2, j’ai le plaisir d’échanger avec Alexandre Dias Da Silva. 

Alexandre a exercé, pendant plusieurs années, un métier dont on ne parle que très peu. Alors que chaque jour, on lit et on utilise le genre de contenus qu’Alexandre peut produire. Chaque jour, ces contenus nous aident à utiliser un site, une application, une solution en ligne, ou toute autre interface. 

Vous me direz que j’ai un don incroyable pour faire du teasing, je sens que le suspense est à son comble… J’en arrête et vous dévoile tout de suite le métier dont on parle dans cet épisode. Et puis, finalement, vous l’avez lu dans le titre : on parle de rédaction technique.

À dire vrai, il ne m’avait pas traversé l’esprit de parler de ce métier. Mais Alexandre a bien heureusement remédié à cela en me contactant et en me proposant de rendre ses lettres de noblesse à la rédaction technique. 

Bonne écoute / lecture ! 

 

 

Notes explicatives

• Product designer : il répond aux besoins des personnes en y apportant des solutions qui s’inscrivent dans la continuité des objectifs d’une entreprise mais aussi de l’environnement technique. En plus de répondre à un besoin, il s’assure également qu’une idée va être viable pour une entreprise et compatible avec toutes les autres fonctionnalités existantes en anticipant les implications qu’entraineront le développement de cette nouveauté (définition de The Design Crew).
• Saas : ou Software as a service, ce sont des logiciels utilisables en ligne, sans qu’il soit nécessaire de les télécharger « en dur » sur notre ordinateur.
• Double-diamant : il s’agit d’une carte visuelle du processus de conception d’un produit ou d’un service. Il se divise en 4 phases : découvrir, définir, développer et livrer.
• Design Thinking : méthodologie transversale pour transformer une idée en action et en prototype, pour répondre à un besoin ou une problématique identifée.
• CMS : ou système de gestion de contenu, est un programme permettant de créer un site internet, un blog ou encore un site e-commerce. 

 

Ressources de l’épisode de podcast

• Simplon.co : réseau de Fabriques solidaires et inclusives qui proposent des formations gratuites aux métiers techniques du numérique en France et à l’étranger.
• Le livre L’Obsession du service client, de Jonathan Lefèvre.
• Pour contacter Alexandre Dias Da Silva, rendez-vous sur LinkedIn ou sur son site internet.

Échanges avec Alexandre Dias Da Silva : la rédaction technique

Salut Alexandre. 

Hello Apolline.

Je suis ravie de t’accueillir sur le podcast. J’ai pour habitude de dire « merci d’avoir accepté l’invitation », mais cette fois-ci, on va dire que les choses se sont inversées : c’est toi qui m’as contactée. Alors doublement « merci », car sans ton e-mail, je n’aurais jamais pensé à parler de rédaction technique. On pourrait penser que la rédaction technique est très loin de l’UX et de la rédaction UX, alors que finalement, on le verra, ce n’est pas si éloigné.

Aujourd’hui, tu es en pleine reconversion pour être product designer, mais c’est de ton ancien métier de la rédaction technique que l’on va parler.
Quel est ton parcours ? Comment en es-tu venu à être rédacteur technique ? Et pourquoi cette reconversion soudaine ?

Effectivement, je me reconvertis, mais je garde une grande affection pour ce métier qui est encore assez méconnu en France malheureusement. J’espère que mon passage ici piquera la curiosité des auditeurs et des auditrices et leur donnera envie, qui sait, de se reconvertir dans ce métier.  

J’espère ! (rires)

C’est un métier qui est vraiment fait pour les gens qui ne se lassent jamais d’apprendre et qui veulent être utiles aux autres. Pour l’instant, je n’en dis pas plus, on va sûrement en reparler dans quelques instants. C’est un métier qui, en tout cas, mérite d’être beaucoup plus connu à mon sens. 

Par rapport à mon parcours, j’ai un background essentiellement littéraire à la base, même si j’ai fait un bac S et tenté une première année de médecine. J’ai fait une fac d’Anglais à Paris. Je me destinais au départ à faire de la traduction littéraire. Puis, arrivé en Master, j’ai finalement bifurqué vers de la recherche en linguistique anglaise, pour finalement me spécialiser en conception de documentation, en Master 2.

Pendant cette année-là, j’ai fait un an d’apprentissage en rédaction technique chez IBM, qui est un des pionniers de la rédaction technique. On avait de grosses équipes de documentation et moi, je rédigeais de la documentation pour un logiciel B2B qui permettait l’automatisation de prises de décisions. Après cette année d’apprentissage, j’ai aussitôt commencé à travailler dans l’équipe « support », que l’on pourrait aussi appeler « service client », pour une start-up SaaS à Paris, qui s’appelait DIMELO et qui commercialisait en B2B des logiciels autour de la gestion de la relation client digitale.
Je parle au passé, car elle a été rachetée par RingCentral 2 ans après mon arrivée. Après le rachat, je suis resté encore 2 ans et je suis passé manager de mon équipe la dernière année de mon contrat. 

Dans mon équipe, on avait une double casquette. C’est assez particulier, donc je vais parler de mon expérience en tant que rédacteur technique, mais aussi en tant qu’« agent de support ».
On était à la fois ceux qui répondaient aux e-mails et aux coups de téléphone de nos clients quand ils avaient des questions d’utilisation ou quand ils rencontraient des problèmes. Donc ça, c’est pour la casquette « support ». On était aussi les personnes en charge d’écrire et de maintenir la documentation, c’est-à-dire les guides utilisateurs et les articles de base de connaissances. En résumé, nous écrivions les modes d’emploi, pour la casquette « rédaction technique ». 

Ensuite, sur les raisons de ma reconversion, je dirais que le support et la documentation ne me suffisaient plus. 

Tu avais fait le tour ?

Je suis quand même resté 4 ans dans cette boîte, j’étais devenu un expert de nos produits. Je les connaissais de fond en comble. Je connaissais aussi très bien nos clients puisque je répondais à leurs questions tous les jours. À force de côtoyer des développeurs, d’être exposé à la technique et aux problématiques de design, de wording… je sentais qu’il m’en fallait plus et j’avais envie d’être plus touche-à-tout, finalement. 

J’ai toujours eu une appétence pour le design et, quand on documente un produit, on subit les décisions de design qui ont été prises en amont et on n’a pas forcément notre mot à dire sur la meilleure façon d’agencer l’interface pour améliorer l’UX. Or, j’avais quand même des avis assez tranchés sur le design, parce que je me suis toujours beaucoup documenté sur le sujet et il m’arrivait de voir des choses avec lesquelles je n’étais pas forcément d’accord. Mais mon rôle ne me permettait pas d’être décisionnaire.
En plus de cela, j’avais des témoignages des clients qui confirmaient mes intuitions.
Parfois, cela pouvait être un peu rageant, surtout quand il fallait documenter après coup une fonctionnalité qui aurait peut-être pu être mieux designée et donc plus facilement expliquée. Voilà, j’avais besoin d’avoir plus d’impact. 

Avant le rachat, on était suffisamment petits pour que je puisse toucher à pas mal d’aspects que j’ai pu évoquer. Après le rachat, vu que RingCentral est une grosse boite américaine (à l’époque, il y avait, je crois, entre 4 000 et 5 000 employés), les équipes étaient largement plus structurées, avec des rôles plus déterminés qu’avant, donc je n’avais plus tout le scope que je pouvais avoir avant.

Il y a aussi le petit côté lifestyle, on va dire, sur le fait que je me retrouvais de moins en moins dans les valeurs du salariat et que je voulais m’essayer au freelancing et ainsi pouvoir créer quelque chose de A à Z. C’est pour cela que je me tourne vers le product design, en freelance. Je pense que c’est le domaine qui rassemble un peu tous ces différents aspects qui me plaisent.

Tu es en formation en ce moment, c’est bien cela ?

Oui, exactement. Je suis en formation chez Simplon. Je suis actuellement en train de développer une expertise sur le développement et le design d’application iOS. J’ai 2 gros mois de formation. En octobre, j’aurais 2 mois de formation sur du product design pur et dur. Ce sera à fond : méthodologie double diamant, design thinking, faire du prototypage d’interface, les problématiques UX/UI aussi… Je pense que ça se complète bien. 

Pour moi, c’était important d’avoir un certain bagage technique pour comprendre les enjeux et les problématiques des développeurs et des équipes produit et business. 

Tu disais qu’en tant que rédacteur technique, il faut vraiment connaître le produit de fond en comble. Au final, c’est le rédacteur technique ou la rédactrice technique qui est l’une des personnes qui connaît le mieux le produit dans une boîte, non ? Je n’y avais pas forcément pensé, mais tu es amené à voir tous les bugs, toute la navigation et les choses qui peuvent manquer.

Totalement, oui. D’ailleurs, pour la petite histoire, lorsqu’on était encore au statut de start-up, chez DIMELO, j’avais le job title « expert produit ». On était appelés en interne « les experts » par nos collègues, car ils savaient qu’ils pouvaient venir nous consulter si jamais ils avaient un petit doute sur comment une fonctionnalité était censée se comporter. Nous étions très impliqués dans l’assurance qualité – la QA – pour faire la chasse aux bugs, que nos clients nous remontaient ou que nous pouvions être amenés à découvrir au détour de tests. 

Être rédacteur technique, c’est aussi tester énormément les produits qu’on documente, jusqu’à les connaître par cœur. Cela fait vraiment partie du boulot. 

Pourquoi as-tu voulu t’orienter vers la rédaction technique ?

Lorsque j’étais encore dans mes études d’anglais, je ne me suis pas dit dès le début : « C’est ça que je veux faire, c’est la rédaction technique qui me passionne ». Non, je l’ai découvert un peu sur le tard, pendant mon année de Master 1, quand j’étais encore en recherche en linguistique anglaise. Je savais, à ce stade-là, que je voulais garder le côté un peu littéraire, pouvoir écrire et utiliser les mots pour communiquer et être utile à des utilisateurs ou même en interne, envers d’autres collègues ou des personnes avec qui je serais amené à travailler. 

Je voulais quelque chose de professionnalisant aussi, qui me permette de mettre un premier pied dans l’entreprise. Or, dans les études littéraires, la plupart des gens se destinent à faire soit de l’enseignement, soit faire une thèse, soit faire de la traduction. Même si au début j’étais très attiré par la traduction littéraire, le style de vie du traducteur ne m’attirait pas plus que cela. Il y avait beaucoup de contraintes qui me déplaisaient. 

Je m’étais dit, au fond, il y a toujours la tech qui me tente… J’ai toujours été un peu un geek sur les bords. Sans être développeur, je ne sais pas créer un logiciel de A à Z, mais je me débrouille plutôt bien et j’ai eu un ordinateur assez petit, donc je passais énormément de temps dessus dans ma jeunesse. Je voulais travailler avec des ordinateurs et faire quelque chose en rapport avec des logiciels, avec de l’informatique.

Quand je suis tombé sur le Master à l’Université Paris-Diderot (qui est devenue Université de Paris) je me suis dit : « C’est parfait, car cela me permet de rester un peu dans les lettres, dans l’industrie des langues, et en même temps, je vais pouvoir aussi bosser dans la tech, dans une boite informatique chez un éditeur de logiciels ». Ce que j’ai réussi à faire, du coup. C’était un peu le meilleur des deux mondes !

Finalement, c’est quoi la rédaction technique ?
On a l’image des notices IKEA qui nous aident à monter des meubles. Je suppose que c’est à peu près la même chose sur un produit digital ? Concrètement, qu’est-ce que c’est ? Est-ce que tu peux donner des exemples pour illustrer ?

Oui, avec plaisir. Pour donner une définition très courte et simple de la rédaction technique : c’est l’activité d’écrire des contenus d’aide qui vont permettre à des utilisateurs ou utilisatrices d’un produit, d’accomplir une tâche donnée. 

Pour être un peu plus concret, les rédacteurs techniques sont ceux qui vont écrire les instructions dans des guides utilisateurs, on parle aussi souvent de documentations, ou « doc » pour faire court. Ces guides vont porter sur des produits dans des industries de pointe comme l’informatique (comme c’était mon cas), mais aussi dans le médical, dans l’aéronautique… Il y a beaucoup de secteurs qui font appel aux savoir-faire des rédacteurs techniques. 

Pour revenir sur les notices IKEA, ce n’est pas un exemple de rédaction technique pure et dure, dans le sens où il n’y a pas de mots dans les notices IKEA. C’est uniquement le langage visuel qui est utilisé. 

Ah, c’est vrai, c’est peut-être pour cela que je ne comprends pas tout (rires) !

Mais c’est très intéressant parce que cela fait partie de ce que l’on pourrait appeler la « communication technique ». Dans le milieu dont je suis issu, on commence par ne plus se concentrer que sur la rédaction technique, mais élargir à la communication plus généralement. Parce qu’on s’est rendu compte que le rôle du rédacteur technique est beaucoup plus large que juste écrire des mots et les publier. 

Ce qui va se passer, c’est qu’on va solliciter tout un tas d’équipes, et on va parfois se rendre compte que quelque chose qui semblait plus ou moins évident, ne l’était pas tellement et qu’un avis n’était pas partagé entre les différentes équipes.
J’ai rencontré pas mal de problématiques de wording, de formulation, de choix des mots, de terminologie… Il pouvait arriver qu’il y ait 3 mots différents pour référer à un même concept, une même fonctionnalité dans l’application. Quand tu commences à creuser, à parler aux gens pour comprendre comment on en est arrivé à avoir 3 mots différents, tu comprends qu’au début, c’était l’équipe technique/les développeurs qui ont choisi un mot. Sauf que ce mot-là il était peut-être beaucoup trop technique pour les utilisateurs, donc on a voulu le simplifier. Après, il y a le marketing qui est passé derrière pour venir rendre un peu sexy le concept et qui a donc choisi un autre mot… 

Tout cela pour dire que dans la communication technique, on a un rôle important de médiateur permettant aux équipes qui, habituellement ne se parleraient peut-être pas ou peu, de venir raccrocher les wagons et ainsi favoriser la communication et éviter le travail en silo.

Cela rejoint beaucoup un des pans du métier d’UX writer, qui est d’harmoniser les contenus et que ce soit cohérent et que tout le monde se serve du même terme.

Oui, carrément !

En tout cas, je suis un grand fan d’IKEA (rires), j’adore leurs notices. Il y a peut-être besoin d’un certain temps avant de comprendre les éléments récurrents. On s’est probablement tous pris la tête à monter un meuble et à se demander « mais elle va où cette pièce ? » en s’arrachant les cheveux, etc. Mais globalement, ça marche très bien. Cela marche très bien parce qu’IKEA a pris en compte, dès la conception des produits, que les utilisateurs/clients vont être amenés à monter les meubles eux-mêmes. Cela fait vraiment partie de l’ADN de marque de prendre en considération que l’expérience est conditionnée à la réussite ou non du montage du meuble. C’est superbe !

As-tu une déformation professionnelle ? Dès que tu rencontres une notice ou tout document de rédaction technique, tu le décortiques, tu as un avis dessus ? 

(rires) Oui ! Surtout sur la mise en page. Là-dessus, je suis assez intransigeant (rires).
Pendant mon année de formation en rédaction technique, on nous disait « lisez, lisez énormément de contenus, ayez un mode d’emploi comme livre de chevet », ce que je n’ai pas appliqué à la lettre (rires) !

Quand j’étais petit, j’adorais au petit-déjeuner avoir un paquet de céréales devant moi et lire tous les apports nutritionnels, tout décortiquer…

Je plaide aussi coupable !

Je me sens moins seul alors (rires) !

En fait, c’est quelque chose qui marque et qui finit par faire partie de toi. Essayer de comprendre comment les choses s’imbriquent, comment agencer l’information pour faire en sorte qu’elle soit parlante et que le sens qui est véhiculé reste intact entre la personne qui émet le message et la personne à l’autre bout qui va le recevoir.

Tu parlais de mise en page… C’est toi qui t’en occupes aussi, en tant que rédacteur technique ?

Ça va dépendre du type d’entreprise, de sa taille, de sa maturité par rapport à la documentation. En général, un rédacteur qui est dans une petite équipe, ou seul, va effectivement se charger de la mise en page et de tout ce qui est lié à ce qu’on pourrait appeler l’« ingénierie documentaire ». 

Il faut savoir que derrière la documentation, notamment la documentation en ligne, comme ce que l’on peut trouver dans des centres d’aide, il y a des mécanismes qui sont mis en place, qui peuvent être assez sophistiqués. Cela peut sous-entendre aussi qu’un rédacteur technique soit non seulement amené à récolter l’information, la retranscrire dans des termes compréhensibles pour les utilisateurs et la publier ; mais aussi gérer toute l’infrastructure qui permet cela. Cela peut être l’administration de CMS (ce sont généralement des CMS très techniques, car adaptés aux besoins du rédacteur technique), l’utilisation de normes qui permet de structurer l’information et de réutiliser les contenus, etc.

Cela peut devenir une usine à gaz, aller très loin dans l’aspect ingénierie… Ce qui ouvre aussi des portes pour des spécialisations potentielles.

En tout cas, la mise en page, c’est très important, du moins ça l’est pour moi. Au début de mon expérience, quand j’ai commencé en start-up, on travaillait simplement avec Google Docs. C’était très rudimentaire, mais il faut savoir que dans des grosses boîtes, on a beaucoup plus de possibilités et on peut arriver à des systèmes très complexes qui permettent de démultiplier les formats de sortie possibles (web, papier, mobile, etc.).

En termes de types de contenus techniques, tu évoquais le guide utilisateurs, l’article, le centre d’aide, la notice… Est-ce que l’on peut imaginer que le rédacteur technique puisse participer à la construction, par exemple, d’un chatbot qui réponde aux besoins et aux interrogations des clients ?

Oui. Je ne connais pas directement de personne qui aurait travaillé là-dessus dans mon cercle proche, mais dans les lectures que j’ai pu avoir (je suis pas mal de blogs autour de la rédaction technique), effectivement, certains rédacteurs techniques sont sollicités pour écrire des contenus sur des chatbots. 

Toutes les problématiques d’onboarding, d’accompagnement des utilisateurs, ainsi que la formation, sont très liées. Souvent, quand on a une personne qui est devenue aussi experte que peut l’être un rédacteur technique, celle-ci devient la « go-to person » car le savoir est là. Elle sait écrire, structurer ses pensées, donc c’est l’idéal ! Bien sûr, d’autres personnes pourraient le faire aussi, ce n’est pas la seule dans l’entreprise, mais c’est une des possibilités. C’est quelque chose qui se fait et j’ai déjà pu lire des témoignages là-dessus.

Pour continuer sur les types de contenus, tu peux aussi rédiger une Foire Aux Questions (FAQ), ou les petites infobulles qu’il peut y avoir dans une interface ?

Complètement. Un rédacteur technique peut totalement être impliqué dans la rédaction de tout ce qui est du type aide embarquée dans le produit (tooltips, infobulles, aides contextuelles, etc.), mais aussi la « copie produit ». Là, cela se recoupe beaucoup avec ce que fait l’ux writer.
J’ai été amené aussi à rédiger des contenus de type note de version (release note), newsletter produit, etc.
Encore une fois, on essaie de communiquer des informations techniques à un public qui n’est pas développeur, donc on a besoin d’avoir une sorte de traducteur qui fait l’interface entre l’utilisateur et les experts (que l’on appelle SMEs, pour Subject Matter Experts). 

Tu as vraiment un rôle hyper important dans la vulgarisation et la simplification de l’information, en fait ?

C’est ça : rendre l’information digeste et accessible, abordable pour notre audience. Donc cela soulève aussi le point de connaître cette audience.

Tu fais partie de quelle équipe, en tant que rédacteur technique ? L’équipe produit ?

Quand j’étais chez IBM, je faisais partie d’une équipe de documentation. On devait être une bonne dizaine, voire plus. C’était quand même une grosse équipe. Pour le coup, on était très spécialisés : chaque rédacteur technique travaillait sur une partie du produit et avait son expertise.

Quand je suis passé en start-up, chez DIMELO, j’étais dans l’équipe support. C’est quelque chose que l’on peut retrouver dans les petites structures. Des personnes au support ont ces deux casquettes et rédigent des articles sur un centre d’aide en ligne. Cela dépend vraiment de la perception que la boîte se fait de la rédaction.
Parfois, cette rédaction sera faite par quelqu’un qui n’a pas le job title de rédacteur technique. Quelqu’un du marketing peut être amené à rédiger des contenus d’assistance, par exemple. Je l’ai déjà vu. Cela varie d’une boîte à l’autre.
Je dirais que la rédaction technique va se rattacher aux équipes documentation, support client, UX design, formation et plus marginalement, marketing.

Tu es amené à travailler avec toutes ces équipes-là, alors ? Est-ce qu’il y a d’autres équipes ?

Les équipes avec lesquelles on travaille le plus, clairement, ce sont les équipes d’experts, ces fameux SMEs. Ce sont eux qui détiennent la connaissance dont on va avoir besoin pour rédiger notre documentation. On dépend d’eux, car souvent, les rédacteurs techniques n’ont pas une expertise très poussée. C’était mon cas quand je suis arrivé, j’ai appris le produit sur le tas. J’allais voir les développeurs pour glaner toutes les informations dont j’avais besoin. Il faut prendre le temps pour interroger ces experts et recueillir les informations. C’est l’équipe avec laquelle on va travailler de façon privilégiée. 

Mais il y a aussi l’équipe produit, pour se coordonner sur le lancement de nouvelles fonctionnalités, par exemple. C’est le cas notamment pour faire en sorte que la documentation soit prête en temps et en heure pour nos utilisateurs. 

On peut aussi travailler avec le marketing pour apprendre à mieux connaître notre audience et ainsi adapter notre écriture, prendre en compte les besoins des utilisateurs. 

Et enfin, cela allait de soi pour moi, le rédacteur technique va travailler main dans la main avec l’équipe support. Les remontées et les demandes que les utilisateurs et clients font à l’équipe support sont une mine d’or d’informations pour les rédacteurs techniques, puisque ça leur permet de voir ce qui, au quotidien, pose problème aux utilisateurs et que l’on pourrait venir résoudre (en partie) grâce à la documentation. 

D’autre part, le support use abondamment de la documentation pour économiser du temps. Souvent, si on sait que la réponse se trouve dans la documentation, on va orienter le client ou l’utilisateur vers cette documentation et essayer de le sensibiliser au fait qu’il y a une base de connaissances dont il peut se servir lui-même. C’est ce que l’on appelle le « self care » dans notre jargon. Il n’est pas forcément obligé à chaque fois de contacter le support pour avoir ces réponses-là. L’équipe support, c’est vraiment une équipe avec qui on travaille main dans la main quand on fait de la rédaction technique, oui. 

C’est plutôt cela que je voyais, notamment dans les petites boîtes : généralement, c’est le service client (ou service support) qui s’occupe de rédiger des contenus d’aide.
Est-ce que tu trouves que le métier de rédacteur technique est assez connu des entreprises, ou pas du tout ?

Je pense que les entreprises commencent à être de plus en plus sensibilisées à ce métier. En France, j’ai le sentiment que, à part dans les très grosses entreprises où ça commence à être très ancré, dans les plus petites structures, ce n’est pas encore quelque chose sur laquelle on va miser dès le départ. J’ai l’impression que certaines entreprises pensent que cela se résume à écrire, donc elles vont chercher quelqu’un qui sait aligner trois mots et puis voilà, cela suffira très bien. Cela peut être justifié, ce n’est pas une critique. 

Au début, lorsqu’on monte une boîte, pour un produit qui est raisonnablement complexe, il n’y a peut-être pas besoin d’embaucher un rédacteur technique à temps plein, il risquerait peut-être de s’embêter.

Une fois que la base documentaire est là, après il y a toutes les questions de maintenance, continuer à l’alimenter, veiller à sa pertinence et à sa mise à jour. Il y a quand même des moments de battement.
C’est pour ça que chez DIMELO, on avait ces deux casquettes-là, à la fois support et rédaction technique, pour avoir une répartition du temps équilibrée et qu’on n’ait pas rien à faire pendant des périodes où il n’y aurait pas de nouvelles fonctionnalités. 

Si la rédaction technique est confiée au service client, je doute que la personne qui est au service client ait les mêmes compétences que celles d’un rédacteur technique… C’est quoi, selon toi, les compétences essentielles d’un rédacteur technique, justement ?  

Je pense que ça demande déjà d’être humble et ouvert aux feedbacks, ouvert aux retours qu’on peut nous faire. Comme dans tous les métiers de rédacteur d’ailleurs. Ce n’est pas propre au métier de rédacteur technique, mais vu que le rédacteur technique n’est pas toujours expert sur son sujet, il aura toujours besoin de confronter ce qu’il a écrit aux avis des experts. 

Au début, lorsque l’on commence à demander du feedback, cela peut être un peu frustrant, parce que l’on se rend compte que l’expert, lui qui a la tête dans le guidon, va souvent trouver qu’on manque de précision, qu’on n’est pas assez exhaustif, qu’on ne rend pas justice à l’ingénierie du produit. Le truc, c’est que quand on écrit de la doc, on n’est pas là pour flatter l’ego de qui que ce soit, mais pour être utile, aider quelqu’un à comprendre comment partir d’un point A pour arriver à un point B. Pour cela, peut-être que l’utilisateur ou l’utilisatrice va avoir besoin de comprendre certains concepts. 

C’est applicable à beaucoup de métiers, mais je dirais qu’il faut aussi beaucoup de bon sens et un esprit critique.

Je pense que c’est la compétence la plus compliquée à avoir, le bon sens !

Oui, c’est facile à dire, mais c’est plus difficile à appliquer. On est confronté à énormément d’informations dans ce métier. Des informations qui, parfois, vont se contredire, qui vont venir de sources plus ou moins douteuses, plus ou moins à jour. Il faut être constamment sur ses gardes.
Par exemple, il y a quelqu’un qui m’avance cette information-là, quel est le statut de mes connaissances vis-à-vis de cela ? Est-ce que la source est fiable ? Est-ce que je peux lui faire confiance ? Est-ce que j’ai pu recouper l’information avec d’autres sources, d’autres personnes, pour m’assurer que ça matche bien ? Il faut avoir un rapport à la vérité quasi obsessionnel, parce que le produit est amené à tellement changer du jour au lendemain, que ce qui est vrai un jour peut devenir faux le lendemain et cela peut être épuisant. Donc, il faut savoir se poser, prendre du recul, savoir ce qu’on sait et ce qu’on ne sait pas. Et c’est OK de ne pas savoir.

Au début, quand on arrive dans une boîte en tant que rédacteur ou rédactrice technique, il y a plein de choses qu’il nous reste à apprendre. C’est très déroutant, parce qu’on sait écrire, mais on ne peut pas écrire dès le début.
En revanche, ce qui serait inacceptable, ce serait d’avancer quelque chose qu’on n’aurait pas pris le soin de vérifier. Pour moi, c’est vraiment l’écueil dans lequel il ne fallait pas tomber, même si parfois cela peut être tentant. 

Quand tu as un client au bout du téléphone, tu ne peux pas lui raconter des histoires et ne pas admettre que tu ne sais pas. On avait des clients compréhensifs et on pouvait leur dire « je ne peux pas vous répondre tout de suite, je n’ai pas l’information, mais je préfère ne pas vous dire de bêtise. Je vais vérifier et je reviens vers vous ».

Voilà, tout cela me semble essentiel, c’est plus des soft skills et pas des compétences dures. Bien sûr, il faut savoir écrire, mais j’ai presque envie de dire que c’est secondaire. Une fois que tu as ces soft skills en place, l’écriture va venir assez facilement. En plus, ce que l’on attend d’un rédacteur ou d’une rédactrice technique, c’est de faire des phrases simples, de ne pas édulcorer son discours. Ce n’est pas de la littérature ni de la poésie. Cela n’a pas vocation à être joli, ni à séduire ou convaincre, comme dans le marketing. La portée est très utilitaire, dans le sens où il y a quelqu’un en face qui veut juste atteindre son but. Comment trouver le minimum de mots pour lui décrire ce qu’il ou elle doit faire ? C’est tout. On essaie de tendre vers des infos brutes, claires, non ambiguës.

Tu parlais d’actualisation. C’est vrai que je n’y avais pas forcément pensé, mais tu as un enjeu énorme d’actualiser régulièrement les contenus ! Cela nécessite vraiment d’être organisé et de communiquer avec les équipes produit, j’imagine ?

Créer la documentation de A à Z, lorsqu’elle n’existe pas encore, c’est presque le plus facile. Oui, cela va représenter beaucoup de travail, pour aller parler avec les experts afin d’extraire les connaissances qu’ils peuvent avoir. Puis une fois que tu as rassemblé toutes les informations et rédiger, il faut ensuite faire en sorte que tout cela reste valide au fil du temps. Or, un produit change très vite. Il faut donc faire une sorte d’inventaire permanent. 

On en vient à la stratégie de contenu, qui est une notion que l’on va retrouver dans d’autres domaines. Il s’agit de savoir ce que l’on a écrit jusqu’à présent, où est-ce que ces contenus sont situés, quel est « l’état de santé » de ces contenus-là, et finalement, quand sait-on qu’il faut les mettre à jour ?
Il faut se rapprocher des équipes produit et des développeurs pour faire en sorte qu’ils sachent qu’on existe et qu’ils nous notifient à temps pour que l’on ne se retrouve pas avec une fonctionnalité qui est passée en production sans avoir été documentée. Là, ce serait le drame, car cela aurait des impacts sur les demandes au support.
Un client par exemple, qui découvre une fonctionnalité qui n’est pas documentée, il a cherché dans la documentation, il n’a rien trouvé et il en vient à écrire un e-mail au support : c’est une situation qui n’est agréable ni pour le support, ni pour le client.

Je suis contente que tu évoques le terme de « stratégie de contenus ». Est-ce que justement, en amont, il y a une stratégie ? Comment définit-on quel contenu d’aide est à écrire plutôt qu’un autre ? Comment le sujet de l’aide est-il choisi ?

Si on a un centre d’aide en ligne, on a souvent des statistiques que l’on peut récupérer et qui permettent de voir les points de friction que peuvent rencontrer les visiteurs du site d’aide. Tu peux prendre en compte des indicateurs comme le nombre de visites, le temps passé sur les pages, la durée de la visite.
Il y a aussi à la fin des articles, une question « ces informations vous ont-elles été utiles ? » à laquelle le visiteur peut répondre en votant oui ou non. 

Ces informations-là vont être remontées aux équipes de documentation et de rédaction technique. Cela peut aider à décider sur quels types de contenus on va se focaliser.
Par exemple, un article qui a énormément de vues, où les visiteurs passent beaucoup de temps, et où il y a de nombreux votes négatifs, c’est que potentiellement, quelque chose ne va pas. Cela peut nous aider à orienter nos priorités. 

Il y a aussi d’autres types de statistiques, comme les recherches infructueuses, pour voir ce que les utilisateurs ont tapé comme termes de recherche, et qui a retourné zéro résultat. C’est intéressant de voir ce que les utilisateurs recherchent, pour éventuellement adapter la terminologie que l’on utilise dans la documentation. Peut-être que ce qu’eux appellent « réseau social », nous, on l’appelle différemment dans notre jargon, mais ce n’est pas parlant pour nos utilisateurs. 

Sinon, au-delà des statistiques du centre d’aide, on peut tout simplement s’adresser au support. Il y a énormément d’informations qui peuvent nous servir pour nous aider à décider des prochains articles qu’on va rédiger ou quels contenus on va devoir améliorer. 

Je voulais aussi jeter un petit pavé dans la mare… (rires) S’il y a beaucoup de documents, guides, un centre d’aide hyper fourni, beaucoup d’explications et de contenus d’aide, etc., est-ce que cela ne voudrait pas dire que le produit est finalement trop compliqué à utiliser ?

De mon point de vue, cela peut être un signal d’alerte, en effet.
Je suis plutôt partisan d’une documentation minimaliste : on ne va pas s’amuser à écrire du contenu pour écrire du contenu. On n’est pas dans une logique de production ou d’enjeu comme peut l’avoir le marketing, pour augmenter la visibilité d’un site ou d’une marque. Dans la documentation technique, la création d’un nouvel article doit être justifiée et s’appuyer sur des données tangibles d’utilisateurs. S’il n’y a pas un besoin fondé, remonté par les utilisateurs, je préfère dire qu’il n’y a pas utilité à donner plus d’information sur cette partie-là du produit. 

Sur des produits très compliqués, très réglementés, je pense à des secteurs comme le médical ou l’aéronautique, où il y a des risques importants de sécurité (blessures, mort), là forcément, on ne va pas faire dans le minimalisme. Enfin, je suppose, je n’ai pas d’expertise dans ces secteurs-là, mais je pense qu’il y a un peu moins de liberté et on est obligé d’être exhaustif et de documenter la moindre fonctionnalité, le moindre bouton.

Tu disais qu’il faut connaître de fond en comble le produit. Est-ce que tu fais aussi de la recherche, pour t’approprier la marque, bien comprendre les utilisateurs, les cibles ?

Oui, c’est clairement un passage obligé. Tout d’abord, il fait connaître les utilisateurs et leur façon d’utiliser le produit. Avant de commencer à documenter une nouvelle fonctionnalité, par exemple, on va passer du temps à comprendre comment la nouvelle fonctionnalité s’intègre dans le produit et à quelles occasions les utilisateurs et utilisatrices vont être amenés à l’utiliser. 

Pour comprendre comment le produit fonctionne, il n’y a pas de mystère, il faut passer énormément de temps dans le produit, à le tester dans tous les sens, appuyer sur tous les boutons et voir comment ils réagissent… On va tomber sur des bugs, que l’on va signaler aux équipes de développeurs. 

La beauté de la chose, quand le rédacteur technique fait bien son travail, c’est que plusieurs heures d’interviews d’experts et de tests pour s’approprier une fonctionnalité du produit, vont finalement aboutir à seulement trois phrases dans la doc (rires) ! C’est assez frustrant de se dire qu’on a passé une journée entière à récolter de l’information et que cela se traduit par trois pauvres lignes ! 

Mais au moins, c’est la bonne information.

Voilà. C’est la juste information. Et il n’y a pas besoin de plus. Ce peut être tentant d’« étaler sa science », sauf que ce n’est pas le but, on ne veut pas perdre l’utilisateur en route. Inutile de donner plus d’information que ce dont il pourrait avoir besoin. 

Une fois que tu as rédigé les contenus d’aide, est-ce que tu les partages avec les autres équipes ? Et pourquoi ?

Pendant la phase de rédaction, on fait faire une relecture par les experts pour être sûr que ce que l’on a écrit colle avec la réalité technique. Même si l’on a passé beaucoup de temps avec les experts, il est possible que ce que l’on a écrit puisse ne pas être juste d’un point de vue technique. Dans ce cas-là, c’est tout l’intérêt d’avoir une relecture par les experts. 

Je ne l’ai pas précisé jusqu’à maintenant, mais la documentation a aussi un rôle crucial en interne. Par exemple, chez DIMELO puis RingCentral, les chefs de projets paramétraient la plateforme pour les clients et ils se référaient fréquemment à la documentation parce qu’ils ne pouvaient pas tout connaître par cœur et n’avaient pas le temps, comme nous pouvions l’avoir, pour explorer à fond le produit. Donc c’est très utile en interne, pour les chefs de projets, comme pour d’autres équipes d’ailleurs. 

Que va apporter ton expérience de rédacteur technique à ton nouveau métier de product designer ?

Je pense que ce qui va le plus me rester et ce qui m’a le plus marqué pendant ces années de rédaction technique, c’est l’aspect terminologique. Pour moi, c’est devenu capital, lorsque l’on se met à travailler en équipe, de se mettre d’accord sur des définitions communes, de savoir quand utiliser un mot, ce à quoi il fait référence très précisément. Si l’on se dit que ce n’est pas nécessaire, on va très vite arriver à une accumulation de malentendus, de quiproquos, et cela peut mener à des erreurs monumentales. Je pense que c’est important de faire ce travail-là, de prendre le temps, même si ce n’est pas un truc très fun à faire, en soi. 

Une des compétences dures qu’on inculque aux rédacteurs techniques en formation, c’est de savoir établir un glossaire. Quand un rédacteur ou une rédactrice technique arrive en entreprise ou dans une équipe qui vient de se former, sa première mission va être de créer un glossaire pour venir définir les termes qu’il a pu entendre et glaner un peu partout. Que ce soient des termes marketing, des termes techniques, il va essayer de créer une sorte d’écosystème, quelque chose qui fait sens, dans son ensemble. 

Il y a aussi tout l’aspect architecture d’information, qui me passionne. C’est une notion que l’on retrouve beaucoup en design également. C’est comment trouver la façon la plus intuitive pour mon utilisateur de comprendre l’information que je lui transmets. Est-ce que la meilleure façon va être de l’afficher sous la forme d’un texte, d’un graphique, d’une image, d’une capture d’écran, d’un tableau ? Il y a différentes façons de représenter une même information. On ne va pas juste choisir celle qui nous plaît le plus. Là, on se pose des questions liées au design et à la psychologie pour savoir quelle est la meilleure façon de présenter l’information pour qu’elle soit le plus rapidement et facilement compréhensible pour les utilisateurs.

J’observe de nombreuses similitudes avec l’UX writing. Au moins, dans ton nouveau métier, tu vas contribuer à diffuser la « bonne parole » : l’importance des contenus dans une interface (rires).

J’y compte bien ! 

Pour toi, qu’est-ce qu’une interface web ou mobile, sans une « bonne » rédaction technique ?

Je dirais que c’est comme mettre un utilisateur au milieu d’un labyrinthe, sans plan pour en sortir. Il va sans doute finir par y arriver, mais cela va lui prendre plus de temps, d’effort et cela risque de le décourager.
J’ajouterais à cela que c’est se priver d’un levier de vente, dans le sens où une documentation technique de qualité, c’est devenu un élément différenciant pour un acheteur. Par exemple, si j’hésite entre 2 produits et que l’un possède un mode d’emploi bien plus clair que l’autre, il y a de fortes chances pour que je me tourne plutôt vers le premier.

Si tu devais résumer notre échange, que retiendrais-tu ?

Un des aspects fondamentaux dans la rédaction technique, c’est le minimalisme. Cela a même eu un impact important sur mon style de vie : quand j’ai commencé à m’intéresser à la rédaction technique, qu’on m’a parlé de minimalisme dans la rédaction, que j’ai regardé des vidéos et des contenus autour du minimalisme en tant que style de vie, je me suis rendu compte que ça me parlait énormément. Cela m’apporte du soulagement : je me dis qu’il n’y a pas besoin de tout décrire, de tout documenter tout le temps, mais plutôt de se demander comment on apporte de la valeur à l’utilisateur. Du coup, il faut connaître l’utilisateur. 

Quand tu mentionnais des exemples de documentations bien trop fournies, qui ne donnent pas envie, dans lesquelles il n’y a aucun effort sur la présentation visuelle, cela renvoie une certaine image de l’entreprise. Ils n’ont peut-être pas beaucoup d’égards pour leurs utilisateurs, ce que je déplore. Donc le minimalisme est une notion qui m’est chère et j’aimerais que plus de monde la partage. 

Je l’espère aussi ! Quand on évoque la rédaction technique, on s’imagine tout de suite des pavés de textes, alors que la concision n’empêche pas la compréhension.

Oui, heureusement, on va dans ce sens.
Par exemple, quand tu achètes un téléphone, tu n’as plus qu’un petit livret de 2 pages – un kit de démarrage – et tout le reste est disponible sur Internet, à la demande. 

As-tu un autre conseil pour rédiger des contenus qui aident les utilisateurs ?

Il est essentiel d’avoir un dialogue régulier avec les équipes du terrain, qui sont en contact direct avec les utilisateurs, ceux qui sont en première ligne. Ils sont confrontés à leurs problématiques, à leur pain points de tous les jours. Ils ont toujours des témoignages à partager et ce serait dommage de ne pas en profiter. J’ai l’impression que dans certaines boîtes, on a tendance à oublier cela et à ne pas valoriser les apports de ces équipes-là. 

La perception que l’on a du service client ou du support est encore un peu archaïque. On imagine les call centers avec des agents dans une salle pleine à craquer, en train de réciter leur script. Ce n’est plus la tendance aujourd’hui. Les boîtes qui veulent être plus innovantes mettent leurs utilisateurs, leurs clients et plus généralement l’humain au premier plan. 

L’important, c’est de ne pas trop se complaire dans une vision hypothétique de nos utilisateurs, mais d’aller voir ce qui se passe dans la vraie vie, sur le terrain, au moment où l’utilisateur ou l’utilisatrice utilise le produit. Il faut aller à leur rencontre autant que possible.

Je suis absolument d’accord avec ce que tu dis. Est-ce que tu as des ressources à partager autour de la rédaction technique ?

Ce n’est pas directement en lien avec la rédaction technique, peut-être plus orienté support/service client : je recommande souvent le livre de Jonathan Lefèvre qui s’appelle « L’obsession du service client ». Jonathan Lefèvre était responsable de l’expérience client chez Captain Train (qui est devenu Trainline). Ce livre regorge de petites pépites, il est plein de bon sens. L’auteur parle beaucoup d’écriture, de rédaction, de l’importance des mots, de transparence, de simplicité. C’était ma Bible au moment où je me posais beaucoup de questions sur le support et sur la direction à prendre.
À voir aussi : son site qui propose des articles très fouillés sur les outils de productivité, j’en raffole (rires) !

Dernière question : où te suivre s’il l’on veut te contacter et échanger avec toi ?

J’ai toujours un onglet ouvert sur LinkedIn, je l’utilise beaucoup pour ma veille.

J’ai aussi un site, en cours de construction… Patience.

Je te souhaite une bonne nouvelle aventure dans ton nouveau métier ! Le freelancing, c’est aussi une belle aventure.

Merci beaucoup !

UX Content Craft, la newsletter

Deux fois par mois, directement dans votre boîte e-mails :

• Bénéficiez d’un condensé de ressources pour progresser en UX writing
• Soyez au courant des actualités liées à l’UX writing & au Content design, notamment en francophonie – jobs, événements, etc.

S’inscrire à la newsletter 

 

On garde le contact ?

Vous avez aimé l’épisode ? Dites-le moi en laissant un commentaire, un like ou une note sur la plateforme sur laquelle vous l’écoutez.
N’hésitez à me faire des feedbacks sur l’épisode, pour prolonger le débat, ou sur le podcast en général. Cela m’aidera à l’améliorer, pour qu’il réponde à vos besoins.