3.4Carte d'empathie & comprendre l'utilisateur
L'essentiel en 30 secondes
- Carte d'empathie : ce que l'usager dit, fait, pense, ressent, voit, entend — peurs et attentes.
- Persona : portrait-type de référence (« que penserait-il de cette solution ? ») pour viser juste.
- Sur du réel : bâtir sur entretiens et observation — jamais sur suppositions inventées.
Mini-cas filé — Sara découvre le vrai besoin
Un usager dit « raccourcissez le formulaire ». Sara observe au lieu d'exécuter : il a peur de se tromper et de perdre sa saisie. Avec une carte d'empathie et un persona (« Yacine, 58 ans, pressé, craint l'erreur »), elle révèle le besoin implicite : sauvegarde automatique + réassurance. Le formulaire ne raccourcit pas — il rassure.
Suite du cas 3.1-3.3 — Sara passe du « moi je pense » au « lui a besoin ».
1. Comprendre la personne concernée
Pour résoudre le bon problème, il faut comprendre en profondeur la personne concernée — le cœur de l'approche centrée utilisateur. La carte d'empathie est un canevas visuel qui structure ce qu'on sait d'un utilisateur.
Elle organise plusieurs dimensions : ce qu'il dit, ce qu'il fait, ce qu'il pense, ce qu'il ressent, ce qu'il voit et entend, ses peurs et ses attentes. La remplir force à se mettre vraiment à sa place.
2. Le persona
Le persona complète l'approche : un portrait-type d'un utilisateur représentatif (nom, profil, contexte, besoins, frustrations, objectifs), qui incarne un segment et sert de référence tout au long du projet (« que penserait notre persona de cette solution ? »).
Ces outils déplacent le regard de « ce que MOI je pense être bien » vers « ce dont l'UTILISATEUR a réellement besoin ». Ils font émerger les besoins implicites, souvent plus importants que les besoins exprimés.
3. S'appuyer sur du réel
Attention : ces outils doivent s'appuyer sur une vraie connaissance des utilisateurs (observation, entretiens), pas sur des suppositions inventées à leur place — sinon on projette ses propres biais avec une fausse impression de rigueur.
Bien utilisés, carte d'empathie et personas garantissent qu'on conçoit pour de vrais gens avec de vrais besoins. C'est la différence entre une solution qui marche et une solution dont personne ne veut.
🔎 Exemple concret — Le besoin implicite
Ce que l'utilisateur dit n'est pas toujours ce dont il a besoin.
Dit : « Je veux un formulaire plus court. »
Besoin implicite (observé) : il a peur de se tromper et de perdre sa saisie → la vraie solution est la sauvegarde automatique + réassurance.Résultat : l'observation révèle le vrai besoin derrière la demande.
Réflexe : rencontrez de vrais utilisateurs avant de modéliser.
Vocabulaire de la section
- Carte d'empathie
- Canevas structurant ce qu'on sait d'un utilisateur (dit, fait, pense, ressent, voit, entend, peurs, attentes).
Exemple simple : Sara remplit : Yacine dit « c'est trop long », pense « je vais me tromper ».
Ce que ce n'est pas : une fiche remplie entre collègues sans aucun usager rencontré.
Réflexe : une carte = un usager réel observé, pas un profil moyen.
- Persona
- Portrait-type d'un utilisateur représentatif (profil, contexte, besoins, frustrations, objectifs) servant de référence.
Exemple simple : « Yacine, 58 ans, pressé, craint l'erreur » affiché pendant le projet.
Ce que ce n'est pas : un prénom + une photo + des clichés sans données.
Réflexe : devant chaque solution : « qu'en penserait Yacine ? ».
- Empathie
- Capacité à comprendre le point de vue et le ressenti de l'autre ; compétence clé de l'approche centrée utilisateur.
Exemple simple : Sara reformule la peur de Yacine avant de proposer quoi que ce soit.
Ce que ce n'est pas : plaquer son propre confort (« moi, ça me va ») sur l'usager.
Réflexe : écouter 2 fois plus que parler en entretien.
- Besoin implicite
- Besoin réel non exprimé directement par l'utilisateur, souvent plus important que le besoin exprimé.
Exemple simple : Le besoin de réassurance derrière « formulaire plus court ».
Ce que ce n'est pas : prendre chaque demande au pied de la lettre.
Réflexe : demander « pourquoi » derrière chaque demande exprimée.
- Approche centrée utilisateur
- Démarche partant des besoins réels de l'utilisateur plutôt que des suppositions du concepteur.
Exemple simple : Tester la sauvegarde auto avec 3 usagers avant de la généraliser.
Ce que ce n'est pas : concevoir pour un usager imaginaire à sa propre image.
Réflexe : aucune décision sans un retour usager récent.
En pratique — Comprendre l'utilisateur (empathie, personas)
- Remplissez une carte d'empathie : ce que l'utilisateur dit, fait, pense, ressent ; ses peurs et ses attentes.
- Créez un ou des personas (portraits-types) comme référence tout au long du projet.
- Cherchez les besoins implicites, frustrations et motivations profondes (au-delà de l'exprimé).
- Appuyez ces outils sur une VRAIE connaissance (observation, entretiens), pas sur des suppositions.
Script prêt à dire — entretien empathie (1 min)
« Racontez-moi votre dernière visite à l'accueil : qu'avez-vous fait en arrivant ? Qu'est-ce qui vous a inquiété ? Si tout était parfait, ça se passerait comment ? » — puis je reformule sans proposer de solution.
À poser à 3 usagers réels : faits, ressentis, idéal — sans défendre la solution maison.
Modèle copier-coller — carte d'empathie + persona
USAGER OBSERVÉ (qui, quand) : _______________
DIT / FAIT : _______________
PENSE / RESSENT : _______________
VOIT / ENTEND : _______________
PEURS / ATTENTES : _______________
PERSONA (prénom + contexte + frustration + objectif) : _______________
BESOIN IMPLICITE : _______________Sans accès direct
Interroger l'accueil et relire réclamations : 10 verbatims valent mieux que zéro entretien.
PME Algérie
Noter les formulations bilingues exactes : le mot qui rassure n'est pas toujours celui du formulaire.
B2B / interne
Observer le collègue usager en situation réelle 20 min : ce qu'il fait contredit souvent ce qu'il dit.
Remote
Partage d'écran + verbalisation à voix haute : voir les hésitations révèle l'implicite.
✓ Bonnes pratiques
- Menez quelques entretiens réels : ils valent mieux que des heures de suppositions.
- Cherchez les besoins implicites, pas seulement ce qui est dit.
- Faites de votre persona une synthèse d'observations, pas une fiction.
✗ Pièges fréquents
- Concevoir pour un utilisateur imaginaire à sa propre image.
- Inventer un persona de clichés (il formalise vos biais).
- Confondre besoin exprimé et besoin réel.
Points clés à retenir
- La carte d'empathie structure ce qu'on sait de l'utilisateur (dit, fait, pense, ressent, peurs, attentes).
- Le persona est un portrait-type d'utilisateur servant de référence tout au long du projet.
- Ces outils déplacent le regard de « ce que MOI je pense » vers « ce dont l'UTILISATEUR a besoin ».
- Ils doivent s'appuyer sur une vraie connaissance (entretiens), pas sur des suppositions inventées.
Défi 48h — appliquez demain
Remplissez 1 carte d'empathie à partir de 2 observations réelles et nommez 1 besoin implicite (modèle ci-dessus). Testez-le auprès d'un usager.
- Je peux remplir une carte d'empathie complète sans inventer.
- J'ai nommé 1 besoin implicite distinct du besoin exprimé.
- Mon persona repose sur du réel, pas des clichés.
Questions fréquentes
Pourquoi se mettre à la place de l'utilisateur ?
Parce que le piège le plus coûteux est de concevoir pour un utilisateur imaginaire à notre image. Or les vrais utilisateurs ont d'autres contextes et contraintes. Se mettre à leur place permet de découvrir leurs besoins réels, y compris implicites, et d'éviter de résoudre le mauvais problème.
Les personas ne risquent-ils pas d'être des inventions ?
Oui, c'est un piège réel. Un persona inventé de clichés formalise nos biais. Il doit s'appuyer sur une vraie connaissance : entretiens, observation, réclamations, échanges avec l'accueil. Si vous n'avez pas accès aux usagers, considérez le persona comme hypothétique et validez-le par le test précoce.
Sara remplit une carte d'empathie entre collègues, sans voir aucun usager. Quel risque ?