Chaque décision de documentation — quoi inclure, combien expliquer, quels mots utiliser — découle d’une seule source : une compréhension claire de la personne pour qui vous écrivez. Sans cela, vous ne faites que deviner. Avec lui, vous avez un filtre fiable pour chaque choix que vous faites.
Votre audience aujourd’hui est plus large qu’avant. Cela inclut toujours le lecteur humain qui essaie d’accomplir quelque chose, mais cela inclut désormais aussi les moteurs de recherche, les moteurs de réponse et les assistants IA qui lisent votre documentation pour cette personne — et parfois leur donnent une réponse sans jamais la soumettre à l’article. Une définition complète de l’audience prend en compte les deux.
Cet article explique comment identifier et décrire votre public, et comment utiliser cette compréhension pour rédiger une documentation réellement utile aux personnes — et aux systèmes — qui en ont besoin.
Pourquoi la définition de l’audience est importante
Le même sujet peut être documenté de manières complètement différentes selon qui lit. Un article sur la configuration des permissions utilisateur, par exemple, paraît très différent lorsqu’il est écrit pour un administrateur système par rapport à un utilisateur débutant. L’administrateur a besoin de précision et de cas limites. L’utilisateur débutant a besoin de contexte, de réassurance et d’étapes claires.
Écrire pour « tout le monde » signifie presque toujours écrire pour personne, eh bien. Lorsque vous essayez de servir tous les lecteurs potentiels dans un seul article, vous finissez soit par submerger les débutants avec des détails, soit par ennuyer les experts avec des explications dont ils n’ont pas besoin.
Comment décrire votre audience
Une description utile du public répond à quatre questions.
Qu’est-ce que votre lecteur sait déjà ?
Identifiez les connaissances de base que votre lecteur apporte à l’article. Cela détermine combien vous devez expliquer et quels termes vous pouvez utiliser sans définition.
Un lecteur sans expérience dans votre domaine a besoin de termes définis, de concepts introduits et d’étapes détaillées. Un lecteur qui travaille quotidiennement dans le domaine n’a besoin de rien de tout cela — il a besoin d’informations précises et efficaces qui respectent son expertise.
Soyez précis. « Utilisateurs techniques » n’est pas utile. « Développeurs logiciels familiers avec les API REST mais nouveaux dans les flux d’authentification » l’est.
Qu’essaie d’accomplir votre lecteur ?
Les lecteurs arrivent à la documentation avec un objectif. Ils veulent accomplir une tâche, résoudre un problème ou comprendre un concept. Comprendre leur objectif vous indique quelles informations doivent être dans l’article et ce qui est le bruit.
Demandez : à quoi ressemble le succès pour ce lecteur ? Lorsqu’ils concluront cet article, que devraient-ils pouvoir faire qu’ils ne pouvaient pas faire auparavant ?
Dans quel contexte se trouve votre lecteur ?
Le contexte façonne la lecture des lecteurs. Un lecteur en pleine session de dépannage frustrée lit différemment de quelqu’un qui explore une fonctionnalité par curiosité. Un lecteur sur un appareil mobile en réunion lit différemment de quelqu’un à un bureau avec deux écrans.
Le contexte vous indique à quel point votre lecteur a de la patience, combien de détails il peut absorber, et à quel point il a besoin d’une réponse avec urgence.
Qu’est-ce que votre lecteur ne sait pas et qu’il doit savoir ?
C’est souvent la question la plus importante, et la plus difficile à répondre. Les lacunes dans les connaissances d’un lecteur ne sont pas toujours évidentes — surtout lorsque vous êtes vous-même un expert du sujet. C’est la « malédiction de la connaissance » : plus on en sait sur quelque chose, plus il est difficile de se souvenir de ce que c’était de ne pas le savoir.
Combattez cela en impliquant de vrais lecteurs dans votre processus de documentation. Les tests utilisateurs, l’analyse des tickets de support et les conversations directes avec les clients sont tous des moyens efficaces de découvrir ce que les gens ignorent réellement.
Niveaux d’audience par expertise
La plupart des bases de connaissances servent plus d’un public. Un schéma courant est d’avoir trois groupes de lecteurs distincts, chacun nécessitant une approche différente.
Débutants
Les débutants ne connaissent pas le produit, le domaine, ou les deux. Ils ont besoin d’une orientation avant l’instruction. Ils bénéficient de synthèses conceptuelles qui expliquent ce qu’est un objet avant d’expliquer comment l’utiliser. Ils doivent préciser les prérequis, numéroter clairement les étapes et indiquer explicitement les résultats pour savoir quand ils ont réussi.
Les débutants se laissent facilement décourager par un jargon inexpliqué, des étapes qui sautent en avant ou des articles qui supposent un contexte qu’ils n’ont pas. Chaque hypothèse inexpliquée est un point de sortie potentiel.
Utilisateurs intermédiaires
Les utilisateurs intermédiaires connaissent les bases et élargissent leur utilisation du produit. Ils n’ont pas besoin d’être accompagnés mais ils ont besoin d’informations complètes. Ils constituent souvent le plus grand groupe dans une base de connaissances et les plus difficiles à rédiger pour eux, car leurs besoins sont les plus variés.
Les utilisateurs intermédiaires bénéficient d’un contenu clair, direct, axé sur les tâches, qui va rapidement au but et fournit suffisamment de contexte pour comprendre le pourquoi de chaque étape.
Utilisateurs avancés
Les utilisateurs avancés — administrateurs, développeurs, utilisateurs avancés — connaissent profondément le produit et ont besoin d’informations précises et détaillées. Ils explorent souvent des cas limites, s’intègrent avec d’autres systèmes ou dépannent des problèmes complexes.
Les utilisateurs avancés sont frustrés par une explication excessive et des préambules inutiles. Ils veulent une précision technique, des références complètes des paramètres et une reconnaissance honnête des limites. Ils tolèrent la densité si cela signifie de la précision.
Niveaux d’audience par visibilité
En plus de l’expertise, l’audience varie également selon qui est autorisé à voir le contenu. Cela affecte non seulement le ton, mais aussi la structure, la profondeur, et l’application même de la recherche et de la découverte par IA.
Documentation publique
La documentation publique est accessible à tous, y compris aux personnes qui ne sont pas encore clientes. Il faut que cela fonctionne pour les lecteurs qui arrivent sans aucun contexte, et il doit être découvrible — ce qui signifie que le SEO, l’AEO et le GEO s’appliquent directement :
- SEO : l’article doit se classer selon les termes qu’un utilisateur potentiel ou existant rechercherait.
- AEO : l’article a besoin d’une réponse claire et extractible en haut, car il peut être affiché sous forme d’extrait ou lu à voix haute par un assistant vocal avant même que le lecteur ne clique.
- GEO : l’article doit être structuré de manière à ce qu’un assistant IA puisse le récupérer et le citer avec précision lorsqu’un utilisateur pose la même question à un chatbot généraliste.
Le contenu public doit supposer la plus large gamme possible de connaissances préalables et ne jamais s’appuyer sur la terminologie interne.
Documentation privée (interne)
La documentation privée est réservée aux employés, aux associés ou à un public interne défini. Il peut supposer en toute sécurité un contexte partagé, un vocabulaire interne et une formation préalable — ce qui lui permet d’être plus dense et plus efficace. La découvrabilité ici concerne la recherche interne, pas les moteurs de recherche publics : le SEO et la GEO pour les systèmes d’IA publics sont sans importance, mais les assistants IA internes (si votre organisation les utilise) bénéficient néanmoins de la même structure claire et d’une terminologie cohérente qui aident la géométrie publique.
La documentation privée peut se permettre de sauter l’orientation dont le contenu public a besoin, mais elle ne doit pas manquer la précision — un public interne sous pression temporelle reste un public qui doit réussir dès la première lecture.
Documentation à public mixte
Certains contenus — pages tarifaires, aperçus de sécurité, guides d’intégration — sont écrits pour un public mixte : en partie public, en partie client authentifié, parfois en interne. C’est le niveau le plus difficile à écrire, car un même article peut devoir satisfaire un client potentiel qui recherche le produit, un client existant qui le configure, et un agent de support pour le dépanner.
Pour des publics mixtes, commencez avec ce dont le groupe le plus large a besoin (généralement le « qu’est-ce que c’est et pourquoi l’utiliserais-je ») et ajoutez des détails de plus en plus spécifiques pour les groupes plus restreints, plutôt que d’essayer de réduire le contenu à quelque chose de trop vague pour quiconque.
Écrire pour des publics multiples
Lorsqu’un seul article doit servir plus d’un public, structurez-le de façon à ce que chaque groupe — humain ou IA — puisse trouver ce dont il a besoin sans avoir à scruter des contenus qui ne leur sont pas destinés.
Une approche efficace consiste à commencer par les informations essentielles dont tous les lecteurs ont besoin, puis à y ajouter des informations de plus en plus détaillées. Les débutants s’arrêtent quand ils ont ce dont ils ont besoin ; Les utilisateurs avancés poursuivent les détails. Cette superposition est aussi précisément ce qui profite à l’AEO et à la GEO : une réponse claire dès le départ pour l’extraction, un détail de soutien ci-dessous pour les lecteurs qui le souhaitent.
Une autre approche consiste à séparer complètement le contenu : maintenir une version destinée aux débutants et une version avancée du même sujet. Cela coûte plus cher à entretenir mais produit des résultats plus satisfaisants pour les deux publics.
Ce qui ne fonctionne pas, c’est d’essayer de servir chaque public dans un seul bloc de texte non différencié. Quand tout le monde est l’auditoire, personne ne l’est — et un système d’IA résumant un article indifférencié a tout autant de chances de produire une réponse non différenciée et inutile.
N’oubliez pas le lecteur IA
De plus en plus, une grande partie de votre public ne lit jamais l’article directement. Ils posent une question à un moteur de recherche, à un assistant IA ou à un chatbot intégré, et ce système lit votre documentation, extrait une réponse et la présente en votre nom. Ce « lecteur » possède ses propres caractéristiques qui méritent d’être conçues :
- Il n’a aucune patience pour les pistes cachées — il a besoin de la réponse clairement en haut de l’article.
- Il ne tolère pas l’ambiguïté — des pronoms vagues, des hypothèses non formulées et une terminologie incohérente augmentent les risques d’un résumé erroné ou brouillé.
- Il ne peut pas poser une question de suivi comme un humain — donc la complétude dans une seule section compte plus, pas moins.
Concevoir pour ce public ne contredit pas la conception pour des lecteurs humains — les pratiques qui rendent un article clair et bien structuré pour une personne (une réponse directe au départ, une idée par section, des termes cohérents) sont les mêmes qui facilitent la récupération et la citation correctes par un système d’IA.
Documenter les décisions de votre audience
Les définitions d’audience ne sont utiles que si elles sont partagées. Notez qui est votre public principal pour chaque section ou type de contenu dans votre base de connaissances — y compris son niveau d’expertise, son niveau de visibilité (public, privé ou mixte), et s’il doit être optimisé pour la découverte publique — et rendez cette définition accessible à tous ceux qui contribuent. Lorsqu’un nouvel auteur rejoint, il devrait pouvoir lire la définition du public et comprendre immédiatement pour qui il écrit.
Consultez périodiquement les définitions du public. À mesure que votre produit grandit et que votre base d’utilisateurs évolue, les personnes — et les systèmes — qui lisent votre documentation changent également.