De la rédaction de la documentation au pilotage des agents qui l’écrivent

À la fin d’un entretien technique que j’ai mené récemment, la candidate m’a confié qu’elle avait failli passer sous silence son travail avec l’IA. Elle craignait que beaucoup de rédacteurs techniques y résistent encore, et comptait donc ne montrer que le côté « classique » du métier. C’est ce moment qui m’a donné envie d’écrire ce texte : le côté classique est précisément celui qui disparaît.

En bref

Je pense que d’ici quelques années, la plupart des entreprises n’embaucheront plus quelqu’un uniquement pour rédiger de la documentation. L’IA le fait déjà. Avec un accès au code, elle rédige la documentation dès qu’un changement ou une version est livré. Le travail du rédacteur technique se recentre sur deux choses : relire ce que produit l’IA et concevoir l’expérience réelle du lecteur. La grammaire n’est plus le goulot d’étranglement ; là-dessus, l’IA s’en sort généralement bien.

Ce n’est pas une mauvaise nouvelle. C’est une promotion, si vous la saisissez.

De rédacteur à chef d’orchestre

Le rôle passe de la rédaction de documentation au pilotage des agents qui la rédigent. Concrètement, votre guide de style cesse d’être un PDF que personne n’ouvre. Il devient le cadre que vous donnez au modèle : quoi dire, comment le dire, quels mots employer et lesquels éviter à tout prix.

Les outils existent déjà. Les skills de Claude, les Gems de Gemini et les fichiers d’instructions comme CLAUDE.md vous permettent d’apprendre une fois pour toutes à un agent votre ton, vos modèles et vos règles, puis de les réutiliser sur chaque page. J’en ai conçu une pour la documentation de Priority Commerce : une skill Claude qui charge le dossier de référence de chaque produit avant d’écrire la moindre ligne. Le vrai gain : les règles vivaient enfin à un endroit où une machine pouvait les suivre.

Ce que la machine rate encore

L’IA facilite les choses. Elle facilite aussi les grosses erreurs si l’on ne fait pas attention. Un paragraphe sûr de lui sur un endpoint qui n’existe pas se lit aussi bien qu’un paragraphe juste.

C’est là que nous intervenons :

• L’exactitude. Quelqu’un doit vérifier le résultat par rapport au produit, pas par rapport à sa vraisemblance.
• Le contexte. Les tickets Jira et quelques dailies ne livrent pas toutes les nuances d’un produit. Savoir à quoi sert une fonctionnalité et qui bute dessus reste un travail humain.
• La cohérence. Il n’a jamais été aussi simple de garder une documentation cohérente, et pourtant les équipes sautent encore la vérification. Un guide de style ne fonctionne que si quelqu’un le fait respecter.
• Le lecteur. La navigation, les exemples, l’ordre d’apparition des informations, le moment où quelqu’un abandonne : c’est de la conception d’expérience, et c’est notre domaine.

Servez-vous aussi de l’IA comme relectrice. Elle n’a rien à modifier. Elle signale simplement ce que vous pourriez corriger, et vous décidez.

Cinq façons de s’y préparer

1. Apprenez à écrire pour des agents. Transformez votre guide de style en instructions qu’un modèle peut suivre : une skill, une Gem, un fichier d’instructions. Si vous savez expliquer vos standards à une nouvelle recrue, vous savez les expliquer à un agent.
2. Entrez tôt dans le cycle de vie. La documentation ne vient pas après le produit. C’est pendant la planification, les exigences et la conception que l’on repère les lacunes, et que l’agent a le plus besoin de votre contexte.
3. Automatisez les tâches ingrates. Les équipes d’ingénierie sont occupées à corriger des bugs et à livrer la fonctionnalité suivante. Si vous mettez en place un pipeline qui transfère la spécification OpenAPI du dépôt vers ReadMe, Mintlify ou GitBook, en gardant les endpoints étiquetés et ordonnés, vous venez de leur faire gagner un sprint. Pas besoin d’être développeur : quelques automatisations simples suffisent.
4. Relisez en éditeur, pas en correcteur. Arrêtez de traquer les virgules. Traquez les faits erronés, les étapes manquantes et les pages qui répondent à une question que personne n’a posée.
5. Soyez proactif. La plupart des entreprises ignorent ce dont un rédacteur technique est capable. Parfois, elles ne savent même pas ce dont elles ont besoin. Vos premières semaines déterminent la façon dont on vous perçoit : proposez, cherchez ce qu’elles pourraient mettre en place et apportez-le avant qu’on vous le demande.

Pourquoi s’adapter compte

Si vous n’êtes à l’aise qu’avec la rédaction de documentation et de notes de version, ce changement va vous frapper durement. Je ne vais pas l’enrober.

Mais si vous apprenez à piloter les outils, vous devenez la personne qui élève le niveau de la documentation et de toute l’expérience qui l’entoure. Pas quelqu’un qui coche des cases, mais quelqu’un qui rend le produit plus simple à comprendre, à intégrer et à maintenir. C’est un meilleur métier que celui que nous laissons derrière nous.

Et rassurez-vous : si vous savez déjà penser au lecteur, à la structure et à la clarté, vous avez la partie difficile. Les outils sont la partie facile. Commencez par une page : rédigez les instructions que vous donneriez à un nouveau collègue et laissez un agent essayer. Puis relisez-la comme si elle était la vôtre, parce qu’elle l’est.