L'âge d'or de la doc ?

Il y a environ deux ans, je me suis embarquée dans une aventure un peu folle : partir au Japon pendant au moins un an. Sans parler japonais, bien sûr, sinon, ce n’est pas drôle. Dans la foulée, il me fallait également un taf.

Il y avait une chose, notamment, qui me passionnait à ce moment-là, que j’avais beaucoup fait dans un ancien travail, jusqu’à ce qu’on me fasse gentiment comprendre que je cassais les pieds de tout le monde avec mon niveau d’exigence sur la question : la doc.

Qu’à cela ne tienne, j’ai décidé de proposer mes services d’auteur technique et d’ingénierie pédagogique. Je me suis créé un compte sur Upwork, en n’ayant absolument aucune idée de comment trouver mes premiers clients. Je suis allée sur TikTok pour voir ce que les girl bosses américaines conseillaient de faire pour décrocher ses premiers clients sur cette plateforme spécifique. Comme toujours, elles n’ont jamais tort. En une semaine je décrochais mon premier contrat.

Un coup de chance ?

La première mission était conséquente : on partait sur plusieurs mois de travail (même en s’aidant de l’IA) autour d’un produit passionnant ; la prestation doublait mon salaire précédent dans un pays où le coût de la vie est bien plus bas qu’en Europe.

J’ai cru que j’étais la personne la plus chanceuse du monde. Quelques jours de prospection, et c’était réglé, alors que tout le monde sur les forums de technical writing annonçait la mort de la profession ?

Les mois passant, j’ai continué de prospecter (paresseusement) en parallèle, j’ai créé un portfolio avec mes réalisations, et j’ai commencé à recevoir des demandes de travail toutes très différentes les unes des autres. Des recruteurs ont commencé à me contacter. Un grand groupe japonais m’a proposé un poste. Et tout cela, uniquement pour une unique tâche : écrire et maintenir de la documentation technique à plein temps. Le métier dont on ne cessait d’annoncer la mort.

Les deux écoles de la doc

Il y a plusieurs écoles, dans l’écriture technique. Il existe, d’un côté, les rédacteurs purs qui travaillent en partenariat avec un SME (Subject Matter Expert) du produit. C’est souvent une méthodologie adoptée par des industries dont le produit peut difficilement être testé par les rédacteurs : l’aéronautique, le médical, le nucléaire ou encore l’industrie lourde. On ne laisse pas un rédacteur démonter un réacteur d’avion, lancer un scanner IRM ou toucher aux commandes d’une centrale juste pour vérifier qu’une procédure tient la route.

De l’autre, il y a les moutons à cinq pattes. Les gens qui non seulement maîtrisent l’écriture technique, mais connaissent le produit du bout des doigts. Ils se rapprochent du statut de SME, mais continuent de travailler étroitement avec, pour faire remonter des bugs ou des questions autour du produit, faire le lien avec les remontées des utilisateurs, etc. Ces personnes ont au moins des compétences en développement informatique de niveau amateur, mais pas toutes.

Dans la deuxième catégorie, les tech writers qui fonctionnent en Docs as Code sont les rois du pétrole : on utilise les mêmes outils que les équipes d’ingénierie, on suit les cycles de releases, on navigue dans le même écosystème.

Je fais partie, bien sûr, de la deuxième catégorie. Et c’est peut-être l’âge d’or pour cette catégorie précise.

Plus que de la doc

Ce qui m’a surprise, c’est la quantité de boîtes tech qui recrutaient des auteurs techniques, à l’ère de l’IA. Naïvement, je croyais qu’elles essaieraient d’automatiser la doc à partir de leur code source. Mais ça ne fonctionne pas très bien. L’IA peut documenter la procédure, mais :

• Elle ne peut pas deviner le modèle mental : dans quel but et pour qui cette fonctionnalité a-t-elle été pensée ?
• Les sources de vérité (générées par IA) (grossière erreur) sont devenues peu fiables : briefs techniques, PRDs, tous se contredisent et deviennent rapidement obsolètes à mesure que l’ingénierie décide de faire pivoter le produit.
• La vitesse de développement s’étant démultipliée, le besoin d’un travail d’ingénierie autour de la connaissance s’est fait plus pressant que jamais : templates, CI/CD, rendering, de la customization poussée en fonction des besoins de chaque entreprise tech.

Et donc le travail autour de la documentation est devenu un travail d’enquêteur, une personne ou une équipe qui se dédie à :

1. Trouver et définir la source de vérité.
2. Lister les cas d’usage avec les chefs de produits ou quiconque est en lien avec les utilisateurs.
3. Écrire un premier jet pour définir le produit en développement (attention : à l’ère de l’IA, tout change rapidement).
4. Tester le produit en staging dans toutes ses facettes, à mesure que celui-ci se développe.
5. Écrire des guides d’utilisation à partir des cas d’usage.
6. Tout recommencer quand l’équipe décide de pivoter à 360 degrés.

De préférence, il ne faut pas être frileux face à l’incertitude et au manque d’organisation qu’entraîne le développement à vitesse grand V.

Lors de la rédaction, il ne s’agit pas de plaquer bêtement des mots un peu simplets sur un fichier. C’est un exercice de projection qu’on réalise, en se mettant à la place d’un lecteur dont c’est le premier jour sur Terre, tout en lui donnant envie d’aller plus loin, en sachant très bien que :

• La doc est lue en diagonale.
• Ce sera probablement un agent qui retransmettra nos mots, et donc aucune ambigüité n’est permise.

En parallèle, il faut identifier les tâches cruciales mais répétitives, qui mériteraient une automatisation, ou un skill dans un agent. Et les implémenter.

Quand j’ai commencé à travailler à plein temps sur la documentation (je dis bien “travailler sur”, et non “écrire de la”, car le travail dépasse largement cela), j’ai trouvé une dénomination pour cette méthodologie assez personnelle que je mettais en place : de la documentation kinesthésique.

Et l’IA, dans tout cela ?

De mon côté, je ne peux absolument pas jeter la pierre à l’IA. J’y trouve largement mon compte. Elle réduit considérablement mon temps de travail grâce à ces outils :

• Des MCPs persos (Model Context Protocol) dans tous les sens : les serveurs de mes clients, la doc existante, l’outil du support, les release notes à venir…
• Des skills pour les tâches répétitives ou de la révision de texte.
• De la génération de code pour tester le produit.
• M’expliquer ce que fait exactement cette partie du code, ou si telle fonctionnalité a telle option, en interrogeant directement le repo en langage naturel.

En général, je commence souvent par une demande simple, depuis le repo de la doc : Liste les pages qui doivent être mises à jour. Car oui, on oublie toujours une section au fin fond du repo, qui mentionne une fonctionnalité complètement obsolète.

Pour la rédaction technique, j’ai beau avoir mené quelques tentatives, ça reste tragique. La prose de l’IA est incompréhensible. Cela a l’air logique, en surface, mais quand on essaie réellement de comprendre, on se sent bête (ce qui dessert l’objectif de la doc). Avec Claude, plus on augmente l’effort, plus il sort de mots alambiqués sans améliorer la syntaxe ou le sens. C’est en général à ce moment que j’ai envie de le baffer.

Mais chacun son travail, après tout.