Il existe un type d'échec qu'aucun dashboard ne détecte. Un utilisateur est à mi-chemin de la configuration de quelque chose, tombe sur un champ dont le sens n'est pas évident, et s'arrête. Il n'ouvre pas de ticket. Il n'ouvre pas votre centre d'aide. Il ne cherche pas. Il laisse l'onglet ouvert, se dit qu'il y reviendra, et n'y revient jamais.
L'aide contextuelle répond exactement à ce moment-là : une assistance qui apparaît là où la confusion se produit, au moment où elle se produit, à propos de ce que l'utilisateur a réellement sous les yeux. C'est l'inverse du modèle traditionnel, qui demande à une personne bloquée d'arrêter ce qu'elle fait, de trouver comment nommer son problème, d'aller ailleurs et de le chercher.
Ce guide explique ce que signifie l'aide contextuelle, en quoi elle diffère de la documentation et du support, les trois types de contexte qui doivent la déclencher, les sept formats que les équipes livrent réellement, comment décider ce qui la mérite et comment savoir si elle a fonctionné.
À retenir
- L'aide contextuelle se définit par son emplacement, pas par son contenu. La même phrase est de la documentation dans un centre d'aide et de l'aide contextuelle à côté du champ qu'elle explique.
- Trois éléments créent le contexte : où se trouve l'utilisateur, dans quel état est son compte et ce qu'il vient de faire. Une bonne aide contextuelle s'appuie sur les trois.
- La meilleure aide contextuelle reste invisible jusqu'à ce qu'on en ait besoin. Les indications permanentes se fondent dans le décor ; l'aide à la demande reste utile.
- Vos tickets de support sont votre backlog. Chaque question répétée est une aide manquante, située à un écran de l'endroit où elle aurait servi.
- Ne faites jamais d'elle la seule copie de l'information. L'aide contextuelle complète la documentation, elle ne la remplace pas.
- Mesurez le comportement, pas les impressions. Savoir si l'utilisateur a terminé la tâche est le seul résultat qui compte.
Qu'est-ce que l'aide contextuelle ? (sens et définition)
L'aide contextuelle, définie
L'aide contextuelle est un guidage délivré dans le produit, au moment où l'utilisateur en a besoin, et limité à ce qu'il est en train de faire. Au lieu de vivre dans un centre d'aide séparé en attendant qu'on la cherche, elle est rattachée à un écran, un champ, un état ou une action, et elle apparaît quand ce contexte est actif. Sa propriété déterminante est la pertinence par l'emplacement : l'utilisateur n'a pas besoin de décrire son problème pour trouver la réponse, parce que la réponse est déjà à côté du problème.
Cette définition en dit plus qu'il n'y paraît. La plupart de l'« aide » dans les logiciels est générique : elle explique une fonctionnalité à personne en particulier, à aucun moment particulier. L'aide contextuelle est indexée sur la situation. Une phrase qui explique ce qu'est un secret de webhook devient de l'aide contextuelle au moment où elle apparaît à côté du champ « secret de webhook », sur l'écran où vous êtes en train d'en coller un, et pas avant.
Pourquoi le moment compte plus que la formulation. Une personne bloquée consacre son attention à la tâche, pas à l'apprentissage. Une aide qui arrive pendant qu'elle a encore le problème en tête ne lui coûte presque rien à lire. La même aide, trouvée dix minutes plus tard après une recherche, lui coûte un changement de contexte, et à ce stade la plupart des gens ont déjà abandonné pour passer à autre chose.
Aide contextuelle, documentation et support : les différences
Ces trois-là sont complémentaires, pas concurrents, et les confondre est la façon dont les équipes se retrouvent avec une magnifique base de connaissances que personne ne lit. Chacun répond à un type de question différent, pour un coût différent.
| Aide contextuelle | Documentation | Support | |
|---|---|---|---|
| Où elle se trouve | Dans l'écran, à côté de l'élément concerné | Une base de connaissances ou un site de documentation | Une personne, une file d'attente ou un chat |
| Qui la déclenche | Le produit, ou un clic de l'utilisateur | L'utilisateur, en cherchant | L'utilisateur, en demandant |
| Idéale pour | Les micro-confusions : que signifie ce champ, que se passe-t-il si je clique ici | La profondeur : procédures complètes, référence, cas particuliers | L'ambiguïté : problèmes propres au compte, cas qui demandent du jugement |
| Coût pour l'utilisateur | Quasi nul, aucun changement de contexte | Une recherche et un changement d'onglet | De quelques minutes à quelques heures d'attente |
| Coût pour vous | Du temps de conception, et de la discipline sur le volume | Rédaction et maintenance | Des effectifs, conversation par conversation |
| Échoue quand | Il y en a trop, ou c'est la seule copie de l'information | Personne ne pense à aller voir | La même question arrive cent fois |
La relation saine entre les trois est un entonnoir qui coule dans le bon sens : l'aide contextuelle absorbe les micro-questions, la documentation absorbe les questions de procédure, et le support traite ce qui demande vraiment un humain. Quand l'aide contextuelle manque, tout dévale vers la file d'attente, un phénomène que notre guide du support in-app et de la déflexion de tickets aborde côté support.
Le lieu, l'état et le moment. La plupart des produits n'utilisent jamais que le premier.
Les trois types de contexte
On comprend généralement « contextuel » comme « sur le bon écran », ce qui ne représente qu'un tiers de l'idée. Il existe trois signaux indépendants, et la différence entre une aide contextuelle correcte et une aide vraiment bonne tient au nombre de signaux que vous utilisez.
L'écran, le panneau, le champ. Le signal le plus simple, et celui dont tous les produits disposent déjà. Il répond à : qu'est-ce que c'est, ce que j'ai devant moi ?
Espace de travail vide, essai qui se termine, aucune intégration connectée, limite du forfait atteinte, première session ou cinquantième. Il répond à : que dois-je faire ensuite, vu où j'en suis ?
Une erreur renvoyée, une validation échouée, une longue pause sur un champ, une troisième tentative de la même action. Il répond à : vous semblez bloqué sur ce point précis.
« Vous êtes sur l'écran d'import (lieu), vous n'avez encore aucune donnée (état), et votre dernier fichier a été refusé (moment). » Cette combinaison mérite d'interrompre. Le lieu seul le mérite rarement.
L'état et le moment sont ce qui distingue l'aide contextuelle de la décoration. Une indication affichée sur l'écran de facturation à tout le monde et pour toujours n'est pas contextuelle : c'est un panneau permanent, et les panneaux permanents cessent d'être lus en une semaine. La même indication, affichée uniquement aux comptes qui n'ont jamais ajouté de moyen de paiement, est une aide. Notre guide des déclencheurs d'onboarding détaille comment déclencher sur l'état et le comportement plutôt qu'au chargement de la page.
Sept formats d'aide contextuelle qui fonctionnent
Presque toutes les mises en œuvre relèvent de l'un de ces sept formats, classés à peu près du moins intrusif au plus intrusif. L'ordre compte : choisissez le format le plus discret capable de porter le message.
-
1. Texte d'aide sous le champ
Une ligne permanente sous un champ qui explique le format attendu ou la conséquence. Toujours visible, elle coûte une ligne d'espace vertical et n'a jamais besoin d'être découverte. Utilisez-la chaque fois que la réponse est courte et que tout le monde en a besoin.
-
2. Icône d'aide à la demande
Un point d'interrogation à côté d'un libellé, qui affiche une explication plus longue au clic ou au focus. L'interface reste épurée tout en rendant la profondeur accessible. Consultez notre guide des tooltips pour les règles d'accessibilité que ce format doit respecter.
-
3. États vides pédagogiques
La surface la plus sous-exploitée des logiciels. Un écran sans données est un écran où rien ne se dispute l'attention, parfait pour expliquer ce qui doit y figurer et comment l'y mettre. Notre guide des états vides en détaille l'anatomie.
-
4. Guidage accolé aux erreurs
Un message d'erreur qui dit ce qui s'est mal passé, pourquoi, et quoi faire ensuite, avec un lien vers l'article pertinent plutôt qu'un code d'erreur. C'est le moment d'aide où l'intention est la plus forte dans tout le produit, et généralement le plus mal servi.
-
5. Hotspots sur une fonctionnalité nouvelle ou cachée
Un marqueur discret sur un élément qui mérite d'être remarqué, et qui s'explique quand on clique dessus. On attire au lieu de pousser. Le guide des hotspots explique à partir de combien on en met trop.
-
6. Un panneau de ressources qui sait sur quelle page il se trouve
Un widget d'aide in-app dont les trois premiers articles changent selon l'écran. C'est le pont entre l'aide contextuelle et votre centre d'aide : le même contenu, mis en avant par l'emplacement plutôt que par la recherche.
-
7. Un court walkthrough contextuel
Deux ou trois étapes, lancées depuis le point de confusion, qui font la chose avec l'utilisateur. Réservez-le aux tâches qui comportent vraiment plusieurs étapes : un walkthrough pour un seul champ relève de la mise en scène.
Trois surfaces, un seul écran. Toute la discipline consiste à choisir laquelle une question donnée mérite.
Le problème du volume. L'aide contextuelle a un mode d'échec que la documentation n'a pas : elle est en concurrence avec l'interface qu'elle aide. Chaque indication, icône ou marqueur consomme un peu du budget d'attention de l'utilisateur, qu'il en ait besoin ou non. Un écran avec neuf éléments d'aide n'en a en pratique aucun, parce que l'utilisateur a appris à ignorer toute cette catégorie visuelle. Dans le doute, retirez-en un.
Comment décider ce qui mérite une aide contextuelle
Le réflexe est d'expliquer tout ce qui semble compliqué. La meilleure méthode consiste à laisser les données choisir, car ce qui déroute les utilisateurs n'est presque jamais ce qui inquiète l'équipe. Trois sources, par ordre d'utilité :
1. Le ticket qui revient
Prenez vos dernières centaines de conversations de support et regroupez-les par écran sur lequel se trouvait l'utilisateur. Tout ce qui est demandé plus de quelques fois depuis le même écran est une aide contextuelle dont la réponse est déjà rédigée : vous avez la formulation, dans les réponses de vos propres agents.
2. La recherche dans le produit qui ne renvoie rien
Si votre widget d'aide a un champ de recherche, ses requêtes sans résultat forment la liste de ce que les utilisateurs s'attendaient à trouver. Si la recherche de votre centre d'aide est séparée, regardez sur quel article les gens arrivent juste après avoir visité un écran donné : cette paire est un emplacement d'aide contextuelle qui attend d'être rempli.
3. L'étape où le funnel décroche
Une étape avec un abandon inhabituel, un temps passé très long ou un taux élevé de tentatives répétées est un signal de confusion, même quand personne ne se plaint. Notre guide du funnel d'onboarding explique comment repérer ces étapes, et le guide de la friction aide à distinguer la friction utile de la friction accidentelle.
Classez ce que vous obtenez par volume × gravité, prenez les cinq premiers et ignorez le reste tant que ces cinq-là ne sont pas en ligne. L'aide contextuelle est l'un des rares domaines où un petit ensemble bien placé bat systématiquement une couverture exhaustive.
Comment mettre en place l'aide contextuelle en six étapes
- Choisissez une confusion appuyée par des données.
- Écrivez la réponse en deux phrases, avec les mots de l'utilisateur.
- Choisissez le format le plus discret capable de la porter.
- Basez le déclenchement sur le lieu, l'état et le moment, pas seulement sur l'URL.
- Prévoyez une sortie et un accès à la version détaillée.
- Observez le comportement que l'aide devait changer, puis gardez-la ou supprimez-la.
1. Partez d'une confusion, pas d'un audit de contenu
Prenez un seul élément de la liste classée. Résistez à l'envie de concevoir un « système d'aide » : les systèmes se conçoivent et ne se livrent jamais, alors qu'une indication sur un champ se livre cette semaine et commence à rapporter immédiatement.
2. Écrivez la réponse avant de choisir le format
Deux phrases : ce que c'est, et quoi faire. S'il en faut cinq, le problème se situe probablement dans l'interface plutôt que dans l'explication, et un texte d'aide est sur le point de devenir un pansement permanent sur un bug de design. Notre guide de la microcopie UX traite du ton à adopter.
3. Choisissez le format le plus discret qui convient
Court et utile à tous → texte d'aide sous le champ. Plus long et occasionnel → icône d'aide. L'écran est vide → état vide. Cela suit un échec → guidage accolé à l'erreur. Plusieurs étapes → court walkthrough. Ne montez d'un cran que lorsque l'option plus discrète ne peut vraiment pas porter le message.
4. Ciblez correctement le déclenchement
Ajoutez l'état et le moment à la condition de page : affichez l'aide uniquement aux comptes qui n'ont pas encore fait l'action, ou seulement après un premier échec. Tout ce qui est affiché à tout le monde et pour toujours sera ignoré par tout le monde en deux semaines, ce qui est le sort habituel de l'aide sous forme de bannière permanente.
5. Prévoyez une sortie et un accès à la version détaillée
Tout ce qui apparaît de lui-même doit pouvoir être fermé, et la fermeture doit être retenue. Tout ce qui résume doit renvoyer vers l'article complet, parce que la version en deux phrases sera fausse pour quelqu'un. L'aide contextuelle ne devrait jamais être le seul endroit où une information existe : conservez la version de référence dans vos guides utilisateur et laissez le texte dans le produit pointer vers elle.
6. Mesurez le comportement, puis gardez ou supprimez
Fixez la condition de succès avant la mise en ligne : moins de tickets depuis cet écran, plus d'achèvements de cette étape, moins de tentatives répétées de cette action. Si aucun de ces indicateurs ne bouge après une période raisonnable, l'aide n'était pas le problème : retirez-la plutôt que de la laisser ajouter du bruit pour toujours.
Mesurer l'aide contextuelle honnêtement
Les métriques tentantes sont les impressions et les clics, et toutes deux ne veulent presque rien dire : une indication que tout le monde voit et dont personne n'a besoin obtient un score brillant en impressions. Les trois qui comptent vraiment sont plus difficiles à manipuler.
La proportion d'utilisateurs qui ont terminé l'action sur cet écran a-t-elle augmenté après la mise en ligne de l'aide ? C'est tout l'enjeu, et cela se mesure écran par écran.
Étiquetez les conversations selon l'écran d'où elles viennent et suivez ce segment précis. Un chiffre global de déflexion masquera l'effet d'une seule bonne indication.
Des fermetures rapides et des vues répétées de la même indication veulent dire la même chose : elle ne répond pas à la question que les gens se posent réellement.
Aide contextuelle : à faire et à éviter
✅ À faire
- Laisser les tickets de support choisir quoi expliquer
- Déclencher sur l'état et le comportement, pas seulement sur l'URL
- Limiter la réponse à deux phrases et renvoyer vers la version détaillée
- Utiliser l'état vide : c'est de l'espace gratuit
- Placer la meilleure aide à côté des erreurs, là où l'intention est la plus forte
- Rendre tout fermable, et faire en sorte que la fermeture soit retenue
- Supprimer les indications qui n'ont pas changé le comportement
❌ À éviter
- Mettre neuf éléments d'aide sur un seul écran
- Faire d'un tooltip la seule copie d'une règle ou d'un format
- Montrer la même indication à tout le monde pour toujours
- Utiliser un walkthrough de sept étapes pour un problème d'un seul champ
- Répondre par un code d'erreur au lieu d'une action à faire
- Livrer de l'aide pour masquer une interface confuse
- Présenter des impressions comme de l'impact
Mettre en place l'aide contextuelle sans temps de développement
Si l'aide contextuelle a tendance à rester en retard sur le produit, c'est parce que chaque élément pris isolément est trop petit pour justifier un ticket. Une indication d'une ligne sur un champ ne vaut pas une place dans un sprint, alors elle attend, et la même question continue d'arriver dans la file d'attente pendant un trimestre de plus.
Kompassify existe pour briser ce cercle. Les tooltips, hotspots, courts walkthroughs, checklists et annonces se construisent visuellement et se publient sur votre produit en production sans nouvelle release, et chacun peut être ciblé sur un segment (comptes sans données, utilisateurs dans leur première semaine, personnes qui viennent d'atteindre un état particulier) pour toucher les utilisateurs qui en ont besoin plutôt que tout le monde. Comme la publication prend quelques minutes, la bonne méthode devient naturelle : livrer l'indication, observer l'écran, la retirer si elle n'a rien changé. Kompassify est gratuit jusqu'à 100 utilisateurs actifs mensuels, les forfaits commencent à $129/mois, et la solution est conforme au RGPD et hébergée dans l'UE.
Répondez à la question là où elle se pose
Ajoutez des tooltips, hotspots, walkthroughs et checklists à votre produit sans ticket de développement, puis ciblez-les par écran, segment et comportement. Gratuit jusqu'à 100 utilisateurs actifs mensuels, forfaits à partir de $129/mois, conforme au RGPD et hébergé dans l'UE.
Commencer gratuitement →L'essentiel en un paragraphe
L'aide contextuelle est un guidage placé là où la confusion se produit plutôt que rangé là où on peut le chercher. Elle est déclenchée par trois éléments (l'écran sur lequel se trouve l'utilisateur, l'état de son compte et ce qu'il vient de faire) et elle prend la forme de textes d'aide sous les champs, d'icônes d'aide à la demande, d'états vides pédagogiques, de guidage accolé aux erreurs, de hotspots, d'un panneau de ressources adapté à l'écran ou d'un court walkthrough, à peu près dans cet ordre d'intrusivité. Laissez vos tickets de support choisir quoi expliquer, limitez la réponse à deux phrases avec un lien vers la version détaillée, déclenchez-la de façon ciblée, et jugez-la sur le fait que les gens ont terminé la tâche, pas sur le nombre de personnes qui l'ont vue.
Questions fréquentes
Qu'est-ce que l'aide contextuelle ?
L'aide contextuelle est un guidage délivré dans le produit, au moment où l'utilisateur en a besoin, et limité à ce qu'il est en train de faire. Au lieu de vivre dans un centre d'aide séparé en attendant qu'on la cherche, elle est rattachée à un écran, un champ, un état ou une action, et elle apparaît quand ce contexte est actif. Sa propriété déterminante est la pertinence par l'emplacement : l'utilisateur n'a jamais besoin de décrire son problème pour trouver la réponse, parce que la réponse est déjà à côté du problème. La même phrase peut être de la documentation dans une base de connaissances et de l'aide contextuelle à côté du champ qu'elle explique : c'est l'emplacement qui fait la différence.
Quelle est la différence entre l'aide contextuelle et la documentation ?
La documentation est exhaustive, vit à son propre endroit et se trouve en cherchant. L'aide contextuelle est ciblée, vit dans l'interface et se trouve parce qu'elle est déjà là. La documentation convient mieux à la profondeur (procédures complètes, référence, cas particuliers) tandis que l'aide contextuelle convient mieux aux micro-confusions, comme le sens d'un champ ou ce qui se passera si vous cliquez sur un bouton. Les deux fonctionnent ensemble : l'aide contextuelle absorbe les petites questions et renvoie vers la documentation pour ceux qui ont besoin de la version longue. L'aide contextuelle ne devrait jamais être le seul endroit où une information existe.
Quels sont des exemples d'aide contextuelle ?
Sept formats couvrent presque toutes les mises en œuvre réelles. Un texte d'aide sous un champ qui explique son format. Une icône d'aide à la demande à côté d'un libellé, qui affiche une explication plus longue. Un état vide pédagogique qui dit ce qui doit figurer sur l'écran et comment l'y mettre. Un guidage accolé aux erreurs, qui explique ce qui s'est mal passé et quoi faire ensuite. Un hotspot qui signale une fonctionnalité nouvelle ou cachée. Un panneau de ressources in-app dont les articles suggérés changent selon l'écran. Et un court walkthrough de deux ou trois étapes, lancé depuis le point de confusion. Ils sont classés à peu près du plus discret au plus intrusif, et le bon réflexe est d'utiliser le plus discret capable de porter le message.
Quand l'aide contextuelle doit-elle se déclencher ?
Trois signaux devraient décider, et la plupart des produits n'utilisent que le premier. Le lieu, c'est l'écran, le panneau ou le champ sur lequel se trouve l'utilisateur. L'état, c'est la situation de son compte : espace de travail vide, aucune intégration connectée, essai qui se termine, limite du forfait atteinte. Le moment, c'est ce qui vient de se passer : une validation échouée, une erreur renvoyée, une longue pause, une troisième tentative de la même action. Une aide qui ne dépend que du lieu devient vite une décoration permanente que tout le monde finit par ignorer en deux semaines. Une aide qui tient compte des trois mérite d'interrompre, parce qu'elle apparaît précisément quand l'utilisateur est dans la situation qu'elle décrit.
Comment décider quoi expliquer avec l'aide contextuelle ?
Laissez les données choisir, car ce qui déroute les utilisateurs n'est presque jamais ce qui inquiète l'équipe. Regroupez vos dernières centaines de conversations de support par écran : tout ce qui est demandé plusieurs fois depuis le même écran est une aide contextuelle dont vos agents ont déjà écrit la formulation. Regardez ensuite les recherches sans résultat dans votre widget d'aide, puis les étapes du funnel qui présentent un abandon inhabituel, un temps passé anormalement long ou des tentatives répétées. Classez le résultat par volume multiplié par gravité, livrez les cinq premiers et ignorez le reste tant que ces cinq-là ne sont pas en ligne.
Peut-il y avoir trop d'aide contextuelle ?
Oui, et c'est la manière la plus courante de rater le sujet. L'aide contextuelle est en concurrence avec l'interface qu'elle est censée aider : chaque indication, icône ou marqueur consomme un peu du budget d'attention de l'utilisateur, qu'il en ait besoin ou non. Un écran avec neuf éléments d'aide n'en a en pratique aucun, parce que les gens apprennent à ignorer toute cette catégorie visuelle. Pire, l'aide sert parfois à masquer un design confus, ce qui rend le problème de fond permanent. Si une explication demande cinq phrases, c'est généralement l'interface qu'il faut changer.
Comment mesurer l'aide contextuelle ?
Pas avec les impressions ni les clics : une indication que tout le monde voit et dont personne n'a besoin obtient d'excellents scores sur les deux. Mesurez plutôt trois choses. La métrique principale est l'achèvement de la tâche sur cet écran précis : la proportion d'utilisateurs qui terminent l'action a-t-elle augmenté après la mise en ligne de l'aide ? La métrique secondaire est le nombre de tickets associés à cet écran, car un chiffre global de déflexion masquera l'effet d'une seule bonne indication. Le garde-fou est la vitesse de fermeture et les vues répétées, car les deux signifient que l'aide ne répond pas à la question que les gens se posent réellement.
L'aide contextuelle est-elle la même chose que l'onboarding ?
Les deux se recoupent mais ne sont pas identiques. L'onboarding est un programme limité dans le temps qui vise à amener un nouvel utilisateur à son premier résultat significatif. L'aide contextuelle est une propriété permanente de l'interface qui sert les utilisateurs à tous les stades, y compris des clients depuis trois ans qui viennent d'ouvrir un écran qu'ils n'utilisent jamais. En pratique, les mêmes formats et souvent les mêmes outils servent les deux, et les meilleurs systèmes d'aide contextuelle naissent du travail d'onboarding. La différence, c'est que l'onboarding se termine et que l'aide contextuelle, elle, ne se termine pas.