Comment l'IA détecte la friction utilisateur : les signaux comportementaux qui déclenchent le coaching proactif

La plupart des produits SaaS ignorent qu'un utilisateur est en difficulté. Ils découvrent la friction via les tickets support, les dashboards de NRR et les enquêtes de départ, tous des indicateurs qui retardent l'information de plusieurs semaines ou plusieurs mois après les faits. L'IA change cela en détectant la friction en temps réel, avant que l'utilisateur ne décroche et ne commence à chercher une alternative. Cet article explique précisément comment.

Qu'est-ce que la friction utilisateur (et pourquoi est-elle si difficile à détecter)

La friction utilisateur se définit comme l'écart entre l'intention d'un utilisateur et sa capacité réelle à accomplir une tâche dans votre produit. L'utilisateur veut exporter un rapport. Il ne trouve pas le bouton. Il cherche, hésite, réessaie, et finit par abandonner. C'est de la friction. Elle peut être légère (quelques secondes perdues) ou paralysante (abandon complet de la fonctionnalité). Dans les deux cas, elle dégrade silencieusement l'expérience perçue et érode la valeur extraite du produit au fil du temps.

Le problème structurel, c'est la majorité silencieuse. Les recherches sur les comportements utilisateurs en SaaS estiment que moins de 5 % des utilisateurs confrontés à une difficulté ouvrent un ticket support ou contactent leur CSM. Les 95 % restants se débrouillent, trouvent un contournement, adoptent une habitude dégradée, ou tout simplement cessent d'utiliser la fonctionnalité. Ces utilisateurs silencieux sont invisibles pour les équipes produit et customer success, jusqu'au jour où ils n'apparaissent plus du tout dans les données d'usage, puis dans le tableau de churn.

L'analytique traditionnelle n'est pas équipée pour capturer ce phénomène. Les métriques classiques : pages vues, durée de session, nombre de connexions, racontent ce qui s'est passé mais pas pourquoi. Un utilisateur qui passe 12 minutes sur une page peut être en train de lire attentivement un contenu dense, ou être complètement perdu sans trouver comment progresser. La donnée brute est identique. Le signal est radicalement différent.

Il faut aussi distinguer la friction de la pause délibérée. Un utilisateur qui réfléchit avant de valider une action critique (suppression de données, envoi d'un contrat) produit les mêmes signaux d'hésitation qu'un utilisateur confus. La distinction entre friction et réflexion active est l'un des défis centraux de la détection comportementale, et l'une des raisons pour lesquelles l'IA nécessite du contexte pour interpréter les signaux correctement. Pour comprendre comment ces signaux s'inscrivent dans une vue d'ensemble des métriques d'adoption, consultez notre guide sur les métriques d'adoption utilisateur 2026.

La taxonomie des signaux de friction comportementaux

Les rage clicks sont entrés dans le vocabulaire courant du product management. Mais ils ne représentent qu'une catégorie parmi six grandes familles de signaux comportementaux que les systèmes de détection de friction surveillent. Comprendre cette taxonomie complète est ce qui sépare une détection superficielle d'une détection réellement précise.

Signaux d'actions répétées rapides (signaux de rage)

Cette catégorie regroupe les comportements où l'utilisateur répète une même action en attente d'un résultat qui ne vient pas. Le signal le plus connu est le rage click : trois clics ou plus sur le même élément en moins de deux secondes. L'utilisateur clique sur un bouton qui ne semble pas répondre, qui charge trop lentement, ou qui n'a pas l'affordance attendue pour l'action qu'il tente d'effectuer.

La navigation arrière rapide est un signal associé : l'utilisateur entre dans une section, constate que ce n'est pas ce qu'il cherche, en ressort dans les cinq secondes, et recommence ce comportement sur plusieurs sections consécutives. Cela indique que la structure de navigation ne correspond pas au modèle mental de l'utilisateur.

Les boucles de resoumission de formulaire constituent un troisième pattern de cette famille : l'utilisateur soumet le même formulaire plusieurs fois avec des données identiques ou légèrement modifiées, sans que le résultat change. Cela pointe vers une validation peu claire, un message d'erreur incompréhensible, ou un retour d'interface insuffisant après soumission.

Ce que tous ces signaux ont en commun : l'utilisateur attend qu'il se passe quelque chose qui ne se produit pas. L'intention est claire, l'obstacle est dans l'interface ou dans la réponse du système.

Patterns d'hésitation et d'inaction

Cette catégorie est plus subtile que les signaux de rage et plus difficile à interpréter sans contexte. Elle regroupe les comportements où l'utilisateur est présent mais n'agit pas.

Le survol curseur sans action se définit comme rester sur un élément d'interface plus de dix secondes sans cliquer ni interagir. L'utilisateur lit, hésite, cherche une confirmation que c'est bien là qu'il doit aller. Ce signal est particulièrement révélateur sur les boutons d'action principaux : un utilisateur qui survole sans cliquer le CTA d'une étape clé de son onboarding est un utilisateur incertain.

Le temps étendu sur une étape de workflow se mesure en comparant le temps passé par l'utilisateur sur une étape donnée avec la durée médiane de cette étape pour les utilisateurs du même segment. Passer trois à cinq fois la durée médiane sur une étape signale presque toujours une friction : incompréhension de ce qui est demandé, prérequis manquant, ou décision bloquante non anticipée.

Le défilement sans interaction est le pattern d'un utilisateur qui parcourt une page de haut en bas, parfois plusieurs fois, sans jamais cliquer sur quoi que ce soit. L'interprétation la plus fréquente : il cherche quelque chose de spécifique que la page ne lui fournit pas clairement, ou l'information qu'il attendait à cet endroit n'y est pas.

Patterns d'abandon et de recul

Cette famille capture les moments où l'utilisateur renonce, partiellement ou totalement, à un objectif qu'il avait commencé à poursuivre. C'est la catégorie de signaux la plus directement corrélée au risque de churn fonctionnel.

Les sorties en milieu de workflow se produisent quand un utilisateur commence un processus multi-étapes mais l'abandonne systématiquement à la même étape, lors de sessions différentes. Un utilisateur qui quitte toujours un processus de configuration à l'étape 3 sur 5 indique que l'étape 3 contient un obstacle non résolu : information manquante, complexité perçue trop élevée, ou conséquence de l'action jugée trop risquée.

L'inversion de progression désigne le fait de défaire des étapes déjà accomplies. L'utilisateur complète l'étape 4, puis revient à l'étape 2 pour modifier quelque chose, puis repart vers l'étape 4 sans réussir à finaliser. Ce pattern révèle souvent que l'utilisateur n'a pas la vision complète du workflow avant de le commencer, ce qui génère des retours en arrière coûteux.

Les sorties de session à des points cohérents sont un signal systémique plutôt qu'individuel : plusieurs utilisateurs distincts quittent l'application précisément au même endroit du parcours. Quand ce pattern émerge à l'échelle, il signale une friction structurelle dans l'interface, pas un problème individuel.

Comportements de recherche d'aide

Cette catégorie regroupe les signaux où l'utilisateur cherche activement une information que le produit ne lui fournit pas en contexte. Ce sont des indicateurs précieux parce qu'ils révèlent les lacunes de l'interface sur des tâches spécifiques.

L'ouverture de documentation en cours de tâche est le signal le plus explicite : l'utilisateur bascule vers la base de connaissances ou l'aide en ligne pendant qu'il est au milieu d'un workflow actif. Il cherche une réponse que l'interface aurait dû lui donner directement, via un tooltip, un exemple, ou une explication contextuelle.

L'initiation du support chat sur des flux spécifiques est un signal à forte valeur diagnostique. Si 30 % des utilisateurs qui ouvrent le chat de support le font depuis la même page ou le même workflow, cette page est un point de friction structurel. La corrélation entre la page d'origine du chat et la nature des questions posées permet de relier précisément la friction à son contexte.

Les requêtes de recherche dans le produit sont souvent sous-exploitées comme signal de friction. Ce que les utilisateurs tapent dans la barre de recherche interne révèle ce qu'ils ne trouvent pas par la navigation normale. Une requête fréquente pour une fonctionnalité pourtant accessible indique un problème de discoverabilité.

Le copier-coller entre applications est un signal de friction de workflow : l'utilisateur déplace manuellement des données d'un outil vers votre produit, ou vice versa, parce que l'intégration attendue n'existe pas ou n'est pas configurée. Ce comportement est détectable via les événements de focus/blur et les patterns de saisie clavier qui ressemblent à un collage plutôt qu'à une saisie manuelle.

Patterns d'erreurs et d'échecs

Cette famille capture les frictions qui se manifestent par des résultats incorrects ou des blocages explicites dans le produit.

Les erreurs de validation répétées surviennent quand un utilisateur rencontre le même message d'erreur de formulaire plusieurs fois de suite. Chaque occurrence signifie que le message d'erreur n'a pas été suffisamment clair pour lui permettre de corriger sa saisie. C'est une friction d'interface pure, souvent résolvable par une amélioration du libellé ou un exemple de format attendu.

L'évitement de fonctionnalités est un signal plus difficile à capter mais particulièrement révélateur : un utilisateur qui n'utilise jamais une fonctionnalité que les utilisateurs au même stade de maturité emploient activement. Cet évitement peut refléter une découverte manquée, une expérience négative passée, ou une perception que la fonctionnalité est trop complexe par rapport à sa valeur perçue.

Le faible taux de complétion sur des étapes spécifiques est la métrique agrégée de cette catégorie : quand une proportion anormalement élevée d'utilisateurs échoue systématiquement au même point d'un workflow, ce point est un obstacle objectif dans l'expérience produit.

Signaux de déclin d'engagement

Cette dernière famille de signaux est la plus préoccupante parce qu'elle indique que l'utilisateur a déjà commencé à se désengager mentalement du produit. Les frictions non résolues des autres catégories se transforment, avec le temps, en déclin d'engagement.

La baisse de fréquence de sessions se mesure en comparant la fréquence de connexion actuelle d'un utilisateur avec son propre historique, pas avec une norme absolue. Un utilisateur qui se connectait cinq fois par semaine et qui descend à deux fois révèle un désengagement significatif, même si deux connexions hebdomadaires reste une fréquence acceptable en valeur absolue.

Le rétrécissement de l'usage fonctionnel est le signal d'un utilisateur qui utilise moins de fonctionnalités ce mois-ci que le mois précédent. Plutôt qu'une adoption progressive qui s'étend, son périmètre d'usage se contracte. Ce signal précède souvent le churn de plusieurs semaines.

Le désengagement des notifications est un signal discret mais fiable : un utilisateur qui ignorait systématiquement les messages in-app auxquels il répondait régulièrement auparavant. Ce changement de comportement indique que le produit a perdu sa saillance dans les priorités de l'utilisateur.

Comment l'IA combine les signaux en modèle de friction

Un signal isolé est rarement suffisant pour conclure à une friction réelle. Un rage click unique peut être un accident. Un utilisateur qui passe deux fois la durée médiane sur une étape peut simplement être interrompu par un appel téléphonique. C'est la combinaison de signaux, ce que les praticiens de la détection comportementale appellent une constellation de signaux, qui donne à l'analyse sa robustesse diagnostique.

Considérons un exemple concret : un utilisateur qui passe 4 minutes sur une étape de configuration (temps étendu), ouvre la documentation en cours de tâche (recherche d'aide), puis quitte le workflow sans le finaliser (abandon). Chaque signal pris isolément est ambigu. Les trois ensemble forment un modèle de friction qui indique avec un haut niveau de confiance que cet utilisateur s'est heurté à un obstacle substantiel sur cette étape précise.

L'IA opère une distinction fondamentale entre friction individuelle et friction systémique. La friction individuelle est une anomalie au niveau d'un utilisateur spécifique : son comportement diverge de ses propres patterns habituels ou des normes de sa cohorte. La friction systémique est un pattern qui se répète à l'échelle du produit : de nombreux utilisateurs distincts rencontrent la même difficulté au même endroit. Les deux requièrent des réponses différentes.

Pour distinguer le comportement d'un utilisateur de la norme, l'IA construit des baselines comportementales à deux niveaux. Le premier niveau est individuel : l'IA apprend le comportement habituel de cet utilisateur spécifique et détecte les écarts par rapport à son propre historique. Le second niveau est collectif : l'IA compare le comportement de l'utilisateur avec les normes de sa cohorte (même segment, même stade d'adoption, même plan). Un utilisateur qui prend deux fois plus de temps qu'un utilisateur moyen de sa cohorte sur une étape donnée mérite une attention particulière.

Le score de friction est la métrique composite qui synthétise cette analyse. Il pondère les signaux selon leur catégorie (les signaux d'abandon et de déclin d'engagement ont un poids plus élevé que les signaux d'hésitation), leur fréquence d'occurrence, et leur récence. Un score de friction élevé mais ponctuel est moins préoccupant qu'un score modéré mais persistant sur plusieurs sessions consécutives.

La dimension temporelle est justement l'un des éléments les plus différenciants de la détection par IA. Une friction détectée lors d'une seule session peut être conjoncturelle. La même friction observée sur trois sessions distinctes au cours d'une semaine indique un obstacle structurel que l'utilisateur n'a pas réussi à surmonter seul. La persistance amplifie la sévérité et accélère le déclenchement d'une intervention. Pour approfondir la distinction entre les approches réactives et proactives de l'accompagnement utilisateur, consultez notre analyse sur le chatbot support versus le coach IA proactif.

Le pipeline détection-intervention

La détection des signaux n'est que la première moitié du système. L'autre moitié est ce qui se passe quand un modèle de friction est confirmé : le déclenchement d'une intervention pertinente, au bon moment, dans le bon contexte.

La surveillance en temps réel repose sur trois sources de données complémentaires. Le traitement du flux d'événements capture chaque interaction utilisateur avec le produit, de chaque clic à chaque soumission de formulaire, et les envoie vers le moteur de détection en quasi-temps réel. Le replay de session permet de reconstruire visuellement le parcours d'un utilisateur sur une page ou un workflow spécifique, ce qui est précieux pour diagnostiquer des patterns d'hésitation ou de confusion d'interface. L'analytique d'usage agrégée alimente les baselines comportementales et permet de distinguer la friction individuelle de la friction systémique.

Le seuil de déclenchement est le paramètre central du pipeline. Quand le score de friction d'un utilisateur dépasse ce seuil, le système engage l'étape suivante : identifier le contenu d'aide le plus pertinent pour cette friction spécifique, et sélectionner le mécanisme de délivrance approprié. Ce seuil est paramétrable : trop bas, le système génère des interventions sur des frictions mineures et crée lui-même de la friction par sur-sollicitation. Trop élevé, des utilisateurs en vraie difficulté passent sous le radar.

L'association friction-contenu est ce qui transforme la détection en valeur concrète. Détecter une friction sans disposer du contenu pour la résoudre ne produit aucun bénéfice pour l'utilisateur. Le système doit être alimenté par une bibliothèque de connaissances structurée : tutoriels vidéo, articles de documentation, walkthroughs pas-à-pas, exemples de cas d'usage. La pertinence de l'association entre le point de friction et le contenu servi est déterminante pour l'efficacité de l'intervention.

Le mécanisme de délivrance varie selon la nature et la sévérité de la friction détectée. Un tooltip contextuel convient pour une friction légère sur un élément d'interface spécifique : il délivre l'information précisément là où l'utilisateur en a besoin, sans interrompre son workflow. Un walkthrough guidé s'adapte mieux à une friction sur un processus multi-étapes : il accompagne l'utilisateur à travers la séquence complète. Une conversation in-app, déclenchée proactivement par le système, est appropriée pour une friction persistante sur plusieurs sessions : elle invite l'utilisateur à interagir et peut collecter des informations sur la nature exacte du blocage.

La distinction entre approche proactive et réactive est au cœur de ce pipeline. Dans un système réactif, l'intervention se déclenche quand l'utilisateur ouvre un chat de support ou crée un ticket. Dans un système proactif, l'intervention se déclenche avant que l'utilisateur ne sente le besoin d'appeler à l'aide, au moment précis où le signal de friction est détecté. C'est cette antériorité qui change l'expérience utilisateur : recevoir de l'aide avant de se sentir bloqué est qualitativement différent de se débattre avec un problème et finir par demander de l'aide.

Une implémentation opérationnelle de ce pipeline est le AI Performance Coach de MeltingSpot, qui surveille les signaux comportementaux entre les sessions dans les logiciels d'entreprise SaaS, associe la friction détectée au contenu existant le plus pertinent dans la base de connaissances du produit, et délivre un guidage contextuel sans que les utilisateurs aient à demander de l'aide. Pour une vue d'ensemble de l'approche, consultez notre guide sur le coach IA pour l'adoption logicielle et notre analyse de l'in-app learning comme avenir de la formation aux logiciels.

Friction individuelle vs friction systémique : pourquoi la distinction est cruciale

Cette distinction est l'une des contributions les plus importantes de l'IA à la gestion de l'adoption produit. Les systèmes d'analytique traditionnels traitent tous les problèmes utilisateur comme des cas individuels à résoudre un par un. L'IA introduit une lecture à deux niveaux qui change fondamentalement les actions qui en découlent.

La friction individuelle signifie que cet utilisateur spécifique est bloqué, mais que les autres utilisateurs traversent la même étape sans difficulté. Le déclencheur approprié est une intervention personnalisée immédiate : un guidage contextuel, un message proactif, ou une mise en relation avec l'équipe customer success pour les comptes à fort enjeu. L'urgence est élevée parce que l'utilisateur est bloqué maintenant, et chaque session supplémentaire sans résolution augmente le risque de désengagement durable.

La friction systémique signifie que la plupart des utilisateurs peinent au même endroit. Le déclencheur n'est plus une intervention individuelle, mais une alerte adressée à l'équipe produit ou UX : ce point du parcours contient un problème d'interface ou de conception qui affecte l'ensemble de la base utilisateurs. Une correction de product va résoudre la friction pour des dizaines ou des centaines d'utilisateurs en même temps, bien plus efficacement que cent interventions individuelles.

Comment l'IA sépare-t-elle les deux ? En surveillant le taux d'occurrence d'un signal de friction à un point donné du produit. Si ce taux dépasse un seuil défini, par exemple 20 % des utilisateurs qui atteignent cette étape, le signal bascule de la catégorie individuelle à la catégorie systémique. Ce seuil est paramétrable selon la nature du produit et la tolérance aux faux positifs.

La valeur de cette intelligence produit va au-delà de l'accompagnement utilisateur. Les données de friction agrégées deviennent un signal de roadmap produit. Les étapes avec les scores de friction systémique les plus élevés sont les candidats les plus objectifs pour la prochaine itération UX. C'est une manière de prioriser le backlog produit à partir de données comportementales réelles plutôt que d'intuitions ou de demandes isolées. Pour une analyse comparative des approches d'accompagnement produit, consultez notre article sur les agents IA versus chatbots pour l'adoption produit.

Limites et implémentation responsable

Tout système de détection comportementale a des limites que toute équipe envisageant son implémentation doit comprendre et anticiper. Les ignorer conduit à des déploiements qui créent autant de problèmes qu'ils en résolvent.

Les faux positifs sont la première limite à adresser. Le cas classique est celui de la pause délibérée confondue avec la confusion : un utilisateur expert qui prend le temps de lire une configuration complexe avant d'agir produit exactement les mêmes signaux d'hésitation qu'un utilisateur débutant qui ne comprend pas ce qui lui est demandé. La réduction des faux positifs passe par le contexte : le rôle de l'utilisateur, son ancienneté sur le produit, son niveau d'expertise déclaré, et ses patterns comportementaux habituels permettent d'interpréter les signaux avec bien plus de précision. Un système qui détecte la friction sans contexte utilisateur va sur-intervenir auprès des utilisateurs experts, ce qui dégrade leur expérience.

Le risque de sur-intervention est le deuxième écueil. Un système trop sensible qui déclenche un guidage à la moindre hésitation détectée crée sa propre friction : les notifications in-app répétées, les pop-ups de guidage non sollicités, les messages proactifs trop fréquents finissent par être perçus comme intrusifs. Les utilisateurs commencent à fermer les interventions par réflexe sans les lire. La règle de base est de définir un délai minimal entre deux interventions sur le même utilisateur, et de diminuer la sensibilité du déclenchement pour les utilisateurs qui ont déjà reçu récemment une intervention.

Les considérations de confidentialité sont un prérequis non négociable. La collecte de données comportementales in-app est soumise au RGPD et aux réglementations équivalentes selon les zones géographiques. Les données qui peuvent légitimement être collectées sans consentement explicite supplémentaire incluent généralement les événements d'interaction avec l'interface (clics, navigations, soumissions de formulaires) dans le cadre de l'exécution du contrat de service. L'enregistrement vidéo des sessions ou la capture du contenu saisi dans les formulaires nécessite un consentement éclairé et une base légale explicite. La règle pratique : collecter les métadonnées comportementales (quoi, quand, combien de fois), pas le contenu.

La période de calibration est une réalité que les équipes sous-estiment souvent. Un système de détection de friction ne fonctionne pas à pleine précision le jour de son déploiement. La construction des baselines comportementales individuelles et de cohorte requiert plusieurs semaines de données. La calibration des seuils de déclenchement nécessite des itérations sur la base des résultats observés. Les premières semaines produiront des faux positifs et des faux négatifs plus fréquents qu'en régime de croisière. Planifier une phase de calibration de quatre à huit semaines avant de déployer le système à pleine sensibilité est une pratique recommandée. Pour approfondir la dimension de l'éducation proactive des utilisateurs dans ce contexte, consultez notre article sur l'éducation client proactive.

FAQ

Quels signaux comportementaux indiquent la friction utilisateur ?

Les signaux comportementaux de friction se répartissent en six catégories : les signaux d'actions répétées rapides (rage clicks, navigation arrière répétitive, resoumissions de formulaire), les patterns d'hésitation et d'inaction (survol curseur prolongé sans clic, temps étendu sur une étape, défilement sans interaction), les patterns d'abandon et de recul (sorties en milieu de workflow, inversion de progression, sorties de session à des points cohérents), les comportements de recherche d'aide (ouverture de documentation en cours de tâche, initiation du chat support, requêtes de recherche interne), les patterns d'erreurs et d'échecs (erreurs de validation répétées, évitement de fonctionnalités, faibles taux de complétion sur des étapes spécifiques), et les signaux de déclin d'engagement (baisse de fréquence de sessions, rétrécissement de l'usage fonctionnel, désengagement des notifications). Aucun signal pris isolément n'est suffisant : c'est la combinaison de plusieurs signaux appartenant à des catégories différentes qui constitue un modèle de friction fiable.

En quoi la détection de friction par IA diffère-t-elle de l'analytique traditionnelle ?

L'analytique traditionnelle mesure ce qui s'est passé de manière agrégée : nombre de sessions, taux de complétion d'un workflow, temps moyen sur une page. Elle répond à la question "combien". La détection de friction par IA répond à la question "pourquoi" en analysant les patterns comportementaux granulaires en temps réel, au niveau de l'utilisateur individuel. Elle compare le comportement actuel d'un utilisateur avec son propre historique et avec les normes de sa cohorte, détecte les écarts qui signalent une difficulté, et déclenche une intervention avant que l'utilisateur n'abandonne ou ne contacte le support. La différence temporelle est fondamentale : l'analytique traditionnelle détecte les problèmes après le fait, souvent dans les données hebdomadaires ou mensuelles. La détection par IA opère en temps réel, pendant que l'utilisateur est encore dans la session où la friction se produit.

L'IA peut-elle détecter la friction sans le consentement de l'utilisateur ?

La collecte des données comportementales in-app nécessite une base légale, mais n'exige pas systématiquement un consentement explicite supplémentaire si elle est couverte par les conditions générales d'utilisation du service et la politique de confidentialité acceptées lors de l'inscription. La règle pratique selon le RGPD : la collecte des métadonnées d'interaction (quelles fonctionnalités sont utilisées, à quelle fréquence, avec quels patterns de navigation) est généralement fondée sur l'intérêt légitime ou l'exécution du contrat. En revanche, l'enregistrement vidéo des sessions avec capture du contenu saisi requiert un consentement explicite. Toute équipe qui déploie un système de détection comportementale doit consulter son responsable de traitement ou son DPO pour valider la base légale spécifique à son contexte et à ses zones géographiques de déploiement.

Que se passe-t-il quand une friction est détectée ?

Quand le score de friction d'un utilisateur dépasse le seuil défini, le pipeline de détection-intervention s'engage en trois étapes. Premièrement, le système identifie le contenu d'aide le plus pertinent pour le point de friction spécifique : article de documentation, tutoriel vidéo, walkthrough guidé, ou exemple de cas d'usage. Deuxièmement, il sélectionne le mécanisme de délivrance adapté à la sévérité et au contexte : tooltip contextuel pour une friction légère et ponctuelle, walkthrough interactif pour une friction sur un processus complexe, message proactif in-app pour une friction persistante sur plusieurs sessions. Troisièmement, si la friction est détectée comme systémique (elle affecte un pourcentage significatif des utilisateurs au même endroit), une alerte est remontée à l'équipe produit ou UX pour déclencher une correction structurelle dans l'interface. L'objectif est que l'utilisateur reçoive l'aide dont il a besoin sans jamais avoir eu à la demander explicitement.