# Ce que les utilisateurs Mac m’ont appris sur la confiance > Une unité de température, une interface sombre inaccessible, un double achat et une objection au prix ont changé ma façon de penser la confiance, la localisation, l’accessibilité et le support Published: 2026-08-16 Quand Mole est passé d’une commande shell à une app Mac, je pensais que l’interface serait la partie difficile. Le vrai travail a été d’abandonner mes propres suppositions. Une personne a acheté l’app deux fois par erreur et a refusé mon offre de rembourser le second achat. Une autre a corrigé l’unité de température que j’avais choisie d’après sa région. Quelqu’un n’a pas pu utiliser l’app parce que son interface sombre imposée était difficile à lire. Une objection directe sur le prix m’a obligé à réfléchir à ce qu’une app payante doit mériter quand des outils gratuits existent déjà. Aucun de ces messages n’est arrivé sous la forme d’une demande de fonctionnalité bien rangée. Chaque conversation a révélé un écart entre la personne que j’imaginais et celle qui utilisait vraiment le produit. Cet écart m’a davantage appris qu’un tableau comparatif ou un graphique de plus. ## La confiance fait partie de la fonction Le double achat m’est resté en tête non parce que la solution était compliquée, mais à cause de la confiance derrière l’erreur. Je pouvais rendre l’argent. La personne avait déjà payé une fois, s’était trompée, puis souhaitait malgré tout laisser le second achat soutenir le travail. C’est généreux, et cela crée aussi une obligation de rendre le produit plus clair et plus sûr. Un utilitaire qui supprime des fichiers demande plus de confiance que la plupart des logiciels. Il faut croire que l’analyse attribue correctement les fichiers, qu’un élément incertain ne sera pas présélectionné et qu’une erreur pourra être récupérée. Une belle interface ne suffit pas à porter cette promesse. Le produit doit montrer le plan, expliquer pourquoi un élément est ignoré, protéger les données partagées et utiliser la Corbeille quand la récupération compte. Ces détails ne sont pas du support autour de la fonction. Ils sont la fonction. Cette expérience a aussi changé ma lecture des compliments. Ils font plaisir, mais la question utile est ce que la personne a confié au produit. Si la réponse est « retirer des fichiers sans m’inquiéter », la prochaine version doit renforcer la vérification et la récupération avant d’ajouter une nouvelle catégorie d’analyse. ## Une région n’est pas un profil de préférences J’ai un jour supposé qu’un Mac configuré pour les États-Unis devait afficher les températures matérielles en Fahrenheit. Un utilisateur m’a expliqué que les températures techniques se lisent habituellement en Celsius, même lorsque la météo et la température du corps utilisent le Fahrenheit. Voir une puce à 110 degrés dans une unité inattendue provoque de l’inquiétude, pas un sentiment de familiarité. Mole utilise maintenant le Celsius par défaut dans toutes les régions et garde le Fahrenheit comme choix explicite. La modification du code était petite, la correction de l’hypothèse beaucoup plus importante. Une région aide à formater la langue, les dates et les nombres. Elle ne révèle pas la façon dont une personne comprend chaque domaine technique. Il est plus sûr de partir de la convention du phénomène mesuré, de la vérifier avec les personnes qui l’emploient et de préserver un choix explicite lorsque les deux formes sont utiles. Plus un produit devine de préférences à partir d’un pays, plus il peut paraître personnalisé tout en devenant moins familier. ## L’accessibilité commence par « je ne peux pas l’utiliser » Mole a travaillé sur les libellés VoiceOver, l’ordre du focus, la réduction des animations et le contraste renforcé. J’avais commencé à considérer que le produit prenait déjà l’accessibilité au sérieux. Puis une personne malvoyante m’a expliqué que le texte blanc de l’interface sombre imposée était difficile à lire. Son système était réglé sur une apparence claire et elle ne gardait que les apps qui la suivaient. Ce retour a changé la nature du problème. L’apparence claire n’était plus une préférence esthétique ni une demande pour un réglage supplémentaire. Pour cette personne, elle décidait si l’app était utilisable. L’interface principale de Mole impose encore aujourd’hui une apparence sombre. C’est donc une lacune réelle, pas une réussite terminée. L’accessibilité n’est pas un badge obtenu après avoir ajouté assez de libellés. Un produit peut bien fonctionner avec VoiceOver et exclure quelqu’un par son contraste, ses couleurs, ses mouvements, la taille de ses cibles ou une décision d’apparence. La question utile n’est pas de savoir si l’app « prend en charge l’accessibilité », mais quelle tâche une personne ne peut toujours pas terminer, avec quels réglages système, et quelle partie de l’interface l’en empêche. ## Une objection sur le prix est aussi une recherche produit Une personne m’a dit franchement que le prix semblait élevé pour un travail qu’une app gratuite pouvait accomplir. Défendre le prix, le baisser immédiatement ou ajouter des fonctions jusqu’à allonger le tableau comparatif auraient été des réactions faciles. Aucune n’aurait répondu à la partie importante du message. Les outils gratuits résolvent réellement de nombreuses tâches de maintenance sur Mac. La CLI open source de Mole reste gratuite, et macOS inclut déjà Moniteur d’activité, Réglages de stockage, Finder et la Corbeille. Une app payante doit mériter sa place en rendant le travail répété plus sûr, en réunissant des informations dispersées et en aidant quelqu’un qui n’ouvrira jamais Terminal à comprendre ce qui va se passer avant l’action. Si un outil gratuit résout déjà bien le problème, le recommander est plus honnête que d’inventer une raison de vendre une app supplémentaire. L’objection est donc devenue un test de positionnement, pas un appel à élargir le produit. Qui reçoit assez de valeur de l’app native pour payer ? Quels outils faudrait-il autrement assembler ? La différence est-elle visible pendant l’essai ? Si ces réponses sont faibles, le marketing ne peut pas les réparer. ## Transformer le récit en hypothèse corrigée Les retours deviennent bruyants lorsque chaque message entre tel quel dans le backlog. Une personne demande un interrupteur, une autre un prix plus bas, une troisième décrit une erreur qui ne se reproduira peut-être jamais. Les compter tous comme des votes pour une fonction efface le contexte qui les rendait utiles.
Un parcours de retour utilisateur part de la tâche bloquée, trouve l’hypothèse produit qui a échoué, vérifie si le problème appartient au produit, puis aboutit à une valeur par défaut modifiée, une correction ciblée ou un refus délibéré, au lieu de placer chaque demande directement dans le backlog
Une conversation utile corrige d’abord la compréhension de l’utilisateur par le produit, puis la feuille de route. Le résultat peut être une nouvelle valeur par défaut, une correction ciblée ou un refus mieux expliqué.
J’essaie désormais de sortir de chaque conversation avec quatre faits : ce que la personne voulait accomplir, l’hypothèse du produit qui était fausse, si l’échec concerne une catégorie de personnes ou cette seule configuration, et si une meilleure valeur par défaut suffit, s’il faut une correction ciblée ou si le produit doit expliquer pourquoi il refuse la demande. C’est plus lent que compter les demandes, mais cela produit moins de réglages et de demi-solutions. La conversation sur la température a changé une valeur par défaut. Celle sur l’apparence a révélé un travail d’accessibilité inachevé. L’objection sur le prix a clarifié la frontière entre la CLI gratuite et l’app payante. Le double achat n’exigeait aucune fonction, mais rappelait le soin dû par un produit auquel on confie des fichiers personnels. ## Laisser la conversation durer assez longtemps Je continue de traiter directement le support parce que les premières conversations sont rarement comprises après un seul message. Une question sur la licence peut cacher une explication confuse du nombre d’appareils. Une demande de remboursement peut révéler une promesse imprécise sur la page produit. Une demande de réglage peut montrer que la valeur par défaut est mauvaise pour tout le monde. L’automatisation devient utile quand la question se répète, que la réponse reste stable et que les exceptions sont comprises. Avant cela, raccourcir la conversation peut supprimer le détail qui aurait amélioré le produit. J’ai développé cette frontière dans [Notes sur la construction d’un produit discret](https://mole.fit/fr/blog/notes-on-building-a-quiet-product). Je me trompe encore dans certains choix. La valeur par défaut de la température a été corrigée, pas l’apparence sombre imposée. Certains retours deviennent du code, d’autres une limite du produit, et d’autres encore une obligation ouverte. L’important n’est pas de dire oui à tout le monde, mais de quitter chaque conversation avec une idée plus exacte des personnes qui utilisent le produit et de ce dont elles ont besoin pour lui faire confiance. Le parcours du script privé à l’app est raconté dans [Du script shell à l’app Mac](https://mole.fit/fr/blog/the-story-of-mole). Les choix derrière la vérification avant suppression, la protection des chemins et les actions récupérables figurent dans [Concevoir Mole pour rester discret](https://mole.fit/fr/blog/the-design-of-mole). --- Canonical HTML page: https://mole.fit/fr/blog/what-mac-users-taught-me Blog index for agents: https://mole.fit/fr/blog/llms.txt Site index for agents: https://mole.fit/llms.txt