Personne ne lit votre documentation — et votre taux d’activation le prouve

Cet article parle de ce fossé : où il s’ouvre, ce qu’il coûte, pourquoi les widgets de chat ne l’ont pas comblé, et ce qui le comble vraiment.

Le paradoxe de la documentation

La documentation a un problème structurel qu’aucune qualité d’écriture ne peut régler. Elle est produite par des gens qui comprennent parfaitement le produit, pour des gens qui n’y comprennent rien, et elle est consultée dans un onglet de navigateur qui n’est pas le produit.

Chacun de ces trois faits provoque un échec bien précis.

Écrite par des experts. La personne qui rédige le guide sait que « connectez votre espace de travail » veut dire cliquer sur l’avatar, puis sur Paramètres, puis sur Intégrations, puis sur la troisième carte. Elle écrit « connectez votre espace de travail » parce que pour elle, c’est l’instruction. L’utilisateur lit, regarde un écran qui compte quarante éléments interactifs, et ne voit rien qui s’intitule « connectez votre espace de travail ».

Écrite pour un lecteur générique. La doc décrit le produit, pas le compte de l’utilisateur. Elle ne peut pas dire « vous avez déjà ajouté deux licences, donc le bouton que vous cherchez reste grisé tant que vous ne passez pas à l’offre supérieure ». Elle décrit le scénario idéal d’un utilisateur qui n’existe pas : pas encore de données, pas de configuration à moitié faite, pas de restriction liée à l’offre.

Lue ailleurs. Dès que l’utilisateur ouvre un onglet de documentation, il a quitté le workflow qu’il essayait de terminer. Il doit garder son intention en mémoire de travail tout en lisant de la prose. La plupart des gens n’y arrivent pas : ils survolent, devinent, et reviennent dans le produit avec une consigne à moitié retenue.

Prenez un workflow que votre équipe estime bien documenté. Regardez un nouvel utilisateur s’y essayer, la doc ouverte sur un deuxième écran. Comptez le nombre de fois où il change de fenêtre. Ce nombre, c’est le vrai coût de votre documentation, et il n’apparaît nulle part dans vos outils d’analyse.

Là où l’activation fuit vraiment

Les entonnoirs d’onboarding sont généralement instrumentés à la mauvaise granularité. Les équipes mesurent inscrit → activé, constatent la chute et concluent que le produit est trop complexe. Mais cette chute n’est pas un événement unique. Ce sont trois moments distincts, qui échouent pour des raisons différentes.

1. La première mise en place

L’utilisateur a une intention — il vient de s’inscrire, il est motivé, il veut voir le produit fonctionner. Ce qui lui manque, c’est l’orientation. Il ne sait pas lequel des huit éléments à l’écran est la première étape. C’est le seul moment où la plupart des produits l’aident, en général avec un product tour : une suite d’infobulles qui mettent en évidence des éléments dans un ordre fixe.

Les visites guidées fonctionnent quand la situation de l’utilisateur correspond aux hypothèses de leur auteur. Elles cassent dès que l’utilisateur clique à un endroit inattendu, arrive avec des données déjà importées, ou dispose d’une offre où l’étape quatre est désactivée.

2. Le deuxième workflow

C’est le tueur silencieux. L’utilisateur a passé la mise en place, entrevu un peu de valeur, et veut maintenant faire ce pour quoi il s’est inscrit — le workflow en plusieurs étapes, conditionnel, réellement complexe, que votre produit est justement là pour rendre possible.

Personne ne fait de visite guidée du deuxième workflow. Il est trop varié pour être scénarisé et trop important pour être sauté. L’utilisateur est donc renvoyé à la documentation, et le paradoxe décrit plus haut reprend la main.

3. La fonctionnalité jamais découverte

La fuite la plus coûteuse ne ressemble pas à une fuite, parce que l’utilisateur ne pose jamais de question. Il ne découvre tout simplement jamais la fonctionnalité qui aurait fait de lui un utilisateur avancé, et il renouvelle avec l’offre la plus basse — ou ne renouvelle pas du tout, parce qu’il n’est jamais allé assez loin pour voir ce qui justifiait le prix.

Tout a l’air d’un usage sain. Le compte se connecte, utilise deux fonctionnalités, et résilie onze mois plus tard sans le moindre ticket ni la moindre plainte. Rien ne passe jamais au rouge dans votre tableau de bord, parce que « l’utilisateur n’a jamais découvert ce qui l’aurait retenu » n’est pas un événement que l’on peut instrumenter.

Pourquoi le widget de chat n’a rien réglé

Depuis dix ans, la réponse du secteur consiste à placer un widget de chat dans un coin de l’écran. D’abord tenu par des humains, puis par des bots, aujourd’hui par des LLM avec votre doc dans une base vectorielle. Cela a aidé — un utilisateur qui peut poser une question dans le produit est mieux loti que celui qui ne le peut pas. Mais cela n’a pas comblé le fossé, et la raison est précise.

Un chatbot répond dans une bulle. Le travail, lui, se fait dans l’interface.

Demandez à un bon bot de documentation « comment configurer le SSO ? » et vous obtiendrez une réponse juste, bien rédigée, en six étapes. Reste à l’utilisateur à faire la traduction que le bot a sautée :

1. Lire la première étape et la garder en mémoire.

2. Parcourir l’interface à la recherche de quelque chose qui corresponde aux mots de la première étape.

3. Deviner lequel de deux boutons presque identiques est le bon.

4. Cliquer, et vérifier si l’écran qui s’affiche ressemble à ce que décrit la deuxième étape.

5. Sinon, décider s’il a mal lu la réponse ou si la réponse est obsolète.

6. Recommencer pour chaque étape restante, en perdant un peu plus confiance à chaque fois.

C’est la taxe de traduction, et elle est prélevée sur chaque réponse d’un widget de chat. Le bot a fait entrer la documentation dans le produit sans y faire entrer le travail.

Un chatbot explique dans une bulle. Un Customer Success Manager va jusqu’au résultat — et ni l’explication ni la bulle n’ont jamais été le sujet.

— Ce que nous avons appris en construisant Barkan

Il existe un second échec, plus subtil. Un chatbot qui lit votre doc sait ce que fait le produit en général. Il ne sait pas ce qu’il y a sur l’écran de l’utilisateur à cet instant : son offre, les champs déjà remplis, le bouton désactivé et pourquoi. Ses réponses sont donc sûres d’elles mais génériques, précisément quand l’utilisateur a besoin de quelque chose de précis.

---

Ce qu’un Customer Success Manager fait autrement

Toutes les entreprises SaaS connaissent déjà la solution, puisqu’elles la déploient déjà — pour leurs plus gros comptes. Donnez à un client un interlocuteur humain attitré qui connaît le produit, suit son usage et l’appelle pour le guider dans les passages difficiles : ce client s’active, développe son usage et reste.

Personne n’a jamais prétendu que ce modèle ne marchait pas. L’argument a toujours été qu’il ne passe pas à l’échelle : impossible de mettre un Customer Success Manager humain sur un compte à 99 $ par mois et de survivre.

La question n’est donc pas de savoir si le modèle du Customer Success Manager fonctionne. C’est de savoir lesquels de ses comportements peuvent passer dans un logiciel. Il y en a quatre.