Mon App Avait des Visiteurs. Zéro Conversion. Une IA Gratuite a Trouvé Pourquoi en 3 Jours.
Vous avez du trafic. Les utilisateurs cliquent, entrent dans l'app, 62% franchissent la porte d'entrée. Et après ça ? Rien ne convertit. Les utilisateurs disparaissent quelque part entre l'arrivée et l'action, et vous n'avez aucune idée d'où.
Un fondateur d'Indie Hackers l'a dit clairement le mois dernier : ne pas connaître son taux de conversion de base, c'est l'impossibilité de mesurer si vos changements fonctionnent vraiment. C'est la partie que personne ne dit à voix haute. Vous avez le trafic. Vous avez la chute. Entre les deux : une boîte noire.
J'aurais pu réécrire les textes, changer les couleurs des boutons, reconstruire l'onboarding de zéro à l'instinct (traduisez : au pifomètre total). À la place, j'ai installé Microsoft Clarity, un outil gratuit sans limite de sessions, et j'ai passé 3 jours à regarder ce que mes utilisateurs faisaient réellement dans l'app. Pas ce que je supposais qu'ils faisaient. Ce qu'ils faisaient vraiment.
Le résultat : 20% des sessions avaient des clics morts. Les utilisateurs tapaient sur un élément décoratif qui semblait interactif, n'allaient nulle part, et partaient. En plus de ça, un défaut structurel que Clarity ne pouvait pas voir tout seul : mon app était une SPA avec une seule URL pour tous les écrans. Les heatmaps étaient aveugles depuis le jour du lancement.
Pourquoi Clarity et Pas les Payants
Hotjar est le choix par défaut sur toutes les listes d'outils SaaS. C'est aussi 39$/mois pour 500 sessions, avec les enregistrements verrouillés derrière des tiers plus chers. Au stade pré-PMF, vous ne payez pas 39$/mois pour découvrir que vos libellés de boutons sont confus. L'outil que vous allez vraiment installer, c'est celui qui ne coûte rien.
Clarity n'a aucune limite de sessions. Enregistrements de sessions, heatmaps, scroll maps, click maps, et scoring de performance Core Web Vitals, tout est gratuit. 1 balise script dans votre <head>, vous collectez des vraies données en 10 minutes. Le ratio signal/effort bat toutes les alternatives payantes avant le product-market fit.
Clarity fait aussi remonter automatiquement les signaux de frustration : rage clicks (utilisateurs qui tapent au même endroit 3 fois ou plus), clics morts, scroll excessif, et retours rapides sont tous signalés sans configuration manuelle d'événements. Vous n'avez pas besoin de savoir ce que vous cherchez. L'outil vous dit quelles sessions valent le coup d'être regardées.
Si vous en êtes au stade où quelque chose vient d'être livré et que vous n'arrivez pas à comprendre pourquoi le tunnel de commande ne convertit pas, Vibe Coding, For Real couvre la décision full stack avant même d'arriver aux analytics. Gratuit sur Kindle Unlimited, conçu pour les builders qui ont tapé exactement ce mur.
Le compromis : les données vivent sur Azure. Stack avec contraintes de conformité lourdes ? Vous savez quoi faire. Pour un outil standard basé sur WooCommerce ou un SaaS précoce sans exigences spécifiques de rétention de données, ce n'est pas un vrai problème.
3 Outils pour 3 Jobs
Le principe avant de toucher à quoi que ce soit : le consommateur des données détermine le bon outil.
Si vous enquêtez manuellement, le dashboard est votre seule option. C'est le seul endroit où les enregistrements de sessions et les heatmaps existent. Pas d'endpoint API, pas de serveur MCP qui vous donne la vidéo d'un vrai utilisateur naviguant dans votre app. Si vous devez regarder, vous ouvrez le navigateur.
Quand vous devez automatiser, tapez directement dans l'API REST. Métriques agrégées via requête GET, poussées vers le stockage local, traitées par votre propre code. Pas d'intermédiaire, pas de surcharge conversationnelle.
MCP plus Claude, c'est pour les requêtes conversationnelles. Demandez en français courant, obtenez une analyse structurée en retour. Mêmes données sous-jacentes que l'API REST, avec des limites identiques. L'interface est l'upgrade, pas les données.
Mode 1 : Clics Morts et le Piège SPA
Dans le premier lot de données Clarity : 20% de sessions avec clics morts, score de performance 91/100, 0 erreur JS, et profondeur de scroll à 86% signifiant que les utilisateurs lisaient au-delà du fold. Et toujours rien ne convertissait.
La discipline qui a changé ma façon de lire Clarity : le dashboard vous dit le QUOI. Arriver au POURQUOI signifie creuser dans le code.
Première hypothèse : le routing. Un état de nav cassé envoyant les utilisateurs vers le mauvais écran après une action. J'ai tiré 30 enregistrements de sessions et regardé dos à dos. Même élément, même endroit, session après session. Les utilisateurs tapaient dessus. Rien ne se passait. Ils réessayaient. Partaient.
(VOUS ÊTES MORT. Cause du décès : une div avec hover state et pas de click handler.)
Il s'est avéré que l'élément était décoratif. Une div stylée qui avait l'air interactive, avait un hover state que j'avais ajouté par habitude pendant le build, et était connectée à absolument rien. 1 utilisateur sur 5 cliquait sur un mur. Je l'avais livré comme ça et jamais remarqué. (J'ai déployé pire. C'est un espace safe.)
Fix : remplacé la div par un bouton câblé à l'action de conversion primaire. Le taux de clics morts a chuté dans le lot d'observation suivant.
Mon gamin est entré pendant que je regardais la session 22 et a demandé pourquoi je regardais une vidéo de quelqu'un fixant un écran sans rien faire. Pas vraiment pu expliquer. "Le travail" couvre beaucoup de terrain apparemment 😅
Puis le problème plus profond a fait surface.
Ça vaut le coup de s'y attarder, parce que ça change la façon dont vous lisez chaque heatmap que vous avez jamais regardée. Clarity organise toutes les données visuelles par URL. Chaque click map, chaque scroll map, chaque heatmap est scopée à un chemin URL spécifique. Pour une app multi-pages traditionnelle, cette structure fonctionne bien. Pour une SPA qui rend 7 écrans différents sous une seule URL /app, ça signifie que chaque interaction à travers chaque écran est agrégée en 1 blob inutile. Un clic mort sur l'écran de listing produit ressemble identiquement à un clic mort sur la confirmation de commande, parce que du point de vue de Clarity, ils se sont passés sur la même page. J'avais fait tourner cette config pendant des mois, regardant des heatmaps agrégées, tirant des conclusions sur le comportement utilisateur, prenant des décisions de design basées sur ces données, et chaque point de donnée était contaminé. Le décalage structurel entre comment les outils d'analytics modélisent les pages et comment les SPA fonctionnent vraiment n'est pas un bug Clarity. C'est un décalage que vous ne captez pas jusqu'à ce que vous ayez déjà construit le mauvais modèle mental de vos utilisateurs.
Les outils d'analytics sont construits autour des URL de pages. Une SPA qui ne change jamais son URL ne leur donne rien avec quoi travailler.
Vos heatmaps mentent depuis le jour du lancement.
Fix : hash routing. /app/#product-listing, /app/#checkout, /app/#confirmation. Chaque écran obtient une URL adressable. Puis event tagging par écran via clarity('set', 'screen', slug) pour que les sessions se segmentent proprement dans le dashboard.
// Fire whenever the active screen changes
router.on('routechange', (screenSlug) => {
clarity('set', 'screen', screenSlug);
});1 URL adressable par écran est aussi un asset marketing. Vous pouvez maintenant pointer une campagne payante directement vers /app/#checkout au lieu de balancer tout le trafic à la porte d'entrée et espérer que le tunnel d'onboarding comble l'écart.
Mode 2 : L'API et Ses Limites Dures
Une fois que vous voulez automatiser les pulls de métriques, zappez le dashboard. Tapez dans la Clarity Data Export API au endpoint project-live-insights. Auth via token : Settings, Data Export, Generate Token.
3 limites à connaître avant d'écrire une seule ligne :
L'API plafonne à 10 requêtes par jour, pas d'allocation burst, pas d'override. (Pensez-y comme une barre de mana qui se reset à minuit. Ne la cramez pas sur des appels de test.) Un cron job qui tourne toutes les heures va foirer avant le matin. Designez votre planning de polling autour de cette contrainte dès le départ.
Chaque requête couvre au maximum 3 jours d'historique. Pas de vue rolling 30 jours, pas de comparaison de tendance en un seul appel. Construisez votre propre couche de stockage, accumulez quotidiennement, dédupliquez sur la date. Après 30 jours vous avez un mois rolling. Après 90 jours vous commencez à voir des signaux de saisonnalité qui valent la peine d'agir.
Chaque requête accepte un maximum de 3 dimensions simultanément. Device, country, et screen en un appel : ça c'est vos 3. Ajoutez une 4ème et la requête échoue. Plus de segmentation signifie plus d'appels et burn de quota plus rapide.
import requests
token = "your_clarity_project_token"
headers = {"Authorization": f"Bearer {token}"}
response = requests.get(
"https://www.clarity.ms/export-data/api/v1/project-live-insights",
headers=headers,
params={
"startDate": "2026-06-11",
"endDate": "2026-06-14",
"dimensions": "device,country,url"
}
)
data = response.json()Ce que l'API REST ne vous donne pas : enregistrements, heatmaps, ou détail au niveau session. Agrégé seulement. Le comportement utilisateur individuel reste en territoire Mode 1.
Si vous faites tourner plusieurs apps et voulez que ces données alimentent quelque chose de plus large, un setup de monitoring SaaS alimenté par Claude est une extension naturelle. Pas un pattern spécifique à Clarity, mais ça ferme la question "est-ce que quelque chose brûle" à travers tout votre portfolio sans checker 5 dashboards.
Mode 3 : Claude et MCP
Le package @microsoft/clarity-mcp-server sur npm (Microsoft officiel) câble Claude dans la même API que vous tapez en Mode 2. La différence, c'est l'interface.
npx @microsoft/clarity-mcp-server --token your_clarity_tokenAvec le MCP connecté dans Claude, vous demandez en français courant :
"Quels écrans ont le taux de clics morts le plus élevé dans les 3 derniers jours ? Compare mobile vs desktop."
"Qu'est-ce que les utilisateurs ont fait immédiatement avant d'atteindre l'écran de commande sans finaliser un achat ?"
Claude retourne une analyse structurée. Des patterns qui prendraient une heure de review manuelle de sessions remontent en moins d'une minute. Poser une question de suivi est instantané. C'est là que MCP gagne sa place : itération rapide sur les hypothèses d'investigation, pas automation par batch.
Ce que MCP hérite de l'API : chaque limite, exactement. Les mêmes 10 requêtes par jour, 3 jours d'historique, et 3 dimensions par requête max s'appliquent ici comme ils le font à l'appel REST brut. Le serveur MCP est un adaptateur de transport, pas une couche de données. Il traduit l'input conversationnel de Claude en appels REST et formate les réponses en retour. Il ne débloque aucune donnée que l'API n'expose pas déjà. Allez-y en attendant une meilleure interface d'investigation pour les mêmes données, pas un superpouvoir.
Le mode qui m'a surpris n'était pas la vitesse des réponses individuelles mais les comparaisons multi-variables. J'ai demandé à Claude de comparer les signaux de conversion entre les sessions avec clics morts et les sessions sans. Cette coupe croisée nécessite 3 appels API séparés avec différentes combinaisons de dimensions, des maths de quota par-dessus, et un merge manuel des réponses. Le MCP a géré tout ça en 1 tour. J'ai écrit 0 ligne de code et obtenu une comparaison propre en moins d'une minute.
Je pense que MCP fonctionne mieux comme outil de sprint d'investigation : brûlez les 10 requêtes quotidiennes sur des tests d'hypothèses ciblés, puis basculez vers un script pour tout ce qui est répétable. Peut-être que je lis ça mal, mais ce split a été clean jusqu'ici.
À noter : une fois que le MCP tape 10 requêtes, c'est fini. Pas de queue, pas de retry. Planifiez vos questions avant d'ouvrir la session, pas pendant. Les demandes exploratoires brûlent le quota vite.
Pour tout ce qui tourne sur un planning, un CLI purpose-built bat MCP pour l'automation de production : pas de cap quotidien, pas de session Claude requise, tourne dans un cron sans overhead. Utilisez MCP pour l'investigation, CLI pour le stuff programmé. Ils couvrent différentes parties du job.
Clics morts : 20% des sessions au départ, visant sous les 5%. Fix déployé, en mesure. Hash routing live, heatmaps propres par écran. Event tagging par écran actif.
3 jours et 1 outil gratuit. Cette URL aurait dû être là depuis le lancement 🤦♂️
Sources
- Microsoft Clarity — enregistrement de sessions, heatmaps, Core Web Vitals, gratuit
- @microsoft/clarity-mcp-server — npm, Microsoft officiel
- Clarity Data Export API — documentation endpoint, limites de taux
Ce post peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission (ça ne vous coûte rien, et ça m'aide à continuer de livrer des articles de qualité chaque jour pour votre plaisir de lecture).