Dans une réunion de déploiement, quelqu’un partage son écran. Il connaît tous les raccourcis, contourne les limites du logiciel avec des tableaux annexes, a créé ses propres modèles et répond aux questions de ses collègues avant même que le support ne le fasse. Quand vient le moment de choisir l’outil suivant, c’est vers lui que les regards se tournent. Il est le power user : l’utilisateur avancé, passionné, parfois indispensable — et rarement représentatif.
Cette figure est familière dans les entreprises, les administrations, les communautés numériques et les équipes créatives. Elle a quelque chose de rassurant : qui mieux qu’un usage intensif peut révéler les forces et les faiblesses d’un produit ? Pourtant, une organisation qui confie trop largement ses choix à ses utilisateurs les plus habiles prend un risque discret. Elle peut construire des outils pour ceux qui savent déjà s’en débrouiller, plutôt que pour ceux qui doivent réellement travailler avec.
Le sujet dépasse la technique. Il touche à une question de pouvoir : qui a le droit de définir ce qu’est un « bon » outil ? Celui qui l’explore avec plaisir, celui qui le subit quotidiennement, celui qui en assure la maintenance, ou celui dont le travail reste invisible dans les démonstrations ?
Le super-utilisateur voit plus loin, mais pas toujours plus large
Le power user n’est pas seulement une personne compétente. C’est souvent quelqu’un qui a développé une familiarité singulière avec un système. Il sait où chercher, accepte de tester, mémorise des conventions obscures, comprend les exceptions. Là où un collègue voit une procédure interminable, il voit une séquence qu’il peut automatiser ou simplifier.
Cette expertise est précieuse. Les utilisateurs avancés repèrent vite les incohérences, imaginent des usages imprévus et savent formuler des demandes concrètes. Ils peuvent aussi jouer un rôle de traducteur entre les équipes métier et les équipes techniques. Dans un environnement complexe, ils évitent que chaque difficulté ne se transforme en ticket ou en réunion.
Mais leur maîtrise modifie leur perception. Une interface qu’ils jugent acceptable peut être déroutante pour un nouvel arrivant. Une procédure qu’ils trouvent rapide suppose parfois des connaissances accumulées au fil des mois. Une fonctionnalité « évidente » pour eux ne l’est qu’après un long apprentissage. C’est le biais de sélection : entendre en priorité les personnes qui parlent le plus aisément de l’outil, parce qu’elles en maîtrisent déjà le langage.
Le danger n’est pas que les power users aient tort. Le danger est de les prendre pour la totalité des utilisateurs. Leur expérience est profonde ; elle n’est pas nécessairement étendue.
Un outil n’est pas intuitif parce qu’un expert le trouve simple : il l’est lorsqu’une personne ordinaire peut accomplir son travail sans devoir devenir experte.
Quand l’exception finit par dessiner la norme
Les outils numériques sont souvent conçus à partir de demandes formulées sous forme de fonctionnalités : un filtre supplémentaire, un export plus complet, une vue personnalisable, une automatisation, un droit d’accès particulier. Or les power users sont particulièrement capables de produire ce type de demandes. Ils ont des scénarios précis, des irritants bien identifiés et, parfois, une solution déjà en tête.
À force de répondre à ces requêtes, un produit peut devenir plus puissant tout en devenant moins praticable. Chaque option semble légitime prise isolément. Leur accumulation produit une interface chargée, des paramétrages difficiles à comprendre et des parcours encombrés. Le logiciel gagne en possibilités ce qu’il perd en lisibilité.
Cette dérive correspond moins à une erreur de conception qu’à une logique d’écoute incomplète. Les demandes sophistiquées sont plus visibles que les renoncements silencieux. Une personne qui ne comprend pas un formulaire ne rédige pas toujours un retour détaillé ; elle contourne, reporte, demande de l’aide ou abandonne. Son expérience laisse moins de traces que celle de l’utilisateur avancé, capable d’argumenter une amélioration dans le vocabulaire du produit.
Il faut donc apprendre à chercher les cas limites sans les confondre avec le cas général. Les cas limites sont essentiels : ils révèlent les fragilités d’un système et les réalités que les procédures standard ignorent. Mais ils ne doivent pas automatiquement devenir le centre de gravité de l’interface commune.
La compétence cachée, ce coût que l’on ne budgète pas
Lorsqu’un outil ne fonctionne bien qu’entre des mains expertes, l’organisation compense par du savoir informel. Une personne devient la référence pour les formules complexes, les droits d’accès, les paramétrages ou les anomalies mystérieuses. Son aide est souvent généreuse, mais elle a un coût : interruptions, dépendance, ralentissement de l’intégration des nouveaux collègues et fragilité lors des absences.
On appelle rarement cela un problème de produit. On parle plutôt d’habitude, de formation insuffisante ou de résistance au changement. Pourtant, si une procédure exige qu’un collègue « qui sait » soit toujours disponible, l’outil a transféré une part de sa complexité sur le collectif.
C’est une forme de dette d’usage. Comme la dette technique, elle ne se voit pas toujours au moment où elle se crée. Elle apparaît plus tard : quand les règles ne sont plus comprises, quand les bricolages se multiplient, quand une migration devient périlleuse ou quand la personne-clé quitte l’équipe. L’organisation découvre alors qu’elle ne possédait pas seulement un logiciel, mais une constellation de connaissances tacites.
Le réflexe consiste parfois à documenter davantage. C’est utile, mais insuffisant. Une documentation qui explique un parcours inutilement compliqué ne le rend pas simple. La meilleure réduction de dette consiste souvent à supprimer des étapes, clarifier des choix ou reconnaître qu’un besoin très spécifique mérite un circuit séparé.
Ne pas choisir entre les experts et les débutants
La réponse n’est évidemment pas d’écarter les power users des décisions. Ce serait se priver d’une intelligence pratique irremplaçable. Il s’agit plutôt de leur attribuer le bon rôle. Ils sont d’excellents éclaireurs, de mauvais échantillons uniques.
Une démarche de design participatif solide fait dialoguer plusieurs expériences. Elle associe les utilisateurs intensifs, mais aussi les personnes occasionnelles, les nouveaux arrivants, les équipes de support, les managers qui lisent les résultats, les personnes chargées de la conformité et celles qui réalisent les tâches répétitives. Chacun voit une partie différente du système.
- Les utilisateurs avancés révèlent les possibilités inexploitées et les besoins complexes.
- Les novices montrent où le langage, les repères et les parcours échouent.
- Les équipes support identifient les difficultés récurrentes, souvent plus parlantes que les demandes les plus élaborées.
- Les responsables opérationnels peuvent évaluer le coût réel d’une fonctionnalité sur les délais, la qualité et la transmission du savoir.
Cette pluralité oblige à poser de meilleures questions. Non pas seulement : « Que faudrait-il ajouter ? », mais aussi : « Qui sera incapable de faire son travail si nous ajoutons cela ? » Ou encore : « Ce besoin est-il fréquent, critique, ou simplement très bien défendu ? »
La maturité consiste à organiser le désaccord
Un bon processus de décision ne cherche pas un utilisateur idéal qui parlerait au nom de tous. Il rend visibles les tensions entre simplicité, profondeur fonctionnelle, sécurité, rapidité et autonomie. Ces tensions ne disparaissent pas avec un meilleur outil : elles doivent être arbitrées.
Cela suppose une forme de souveraineté d’usage. Les personnes qui travaillent avec un outil doivent pouvoir signaler ce qui les entrave, comprendre pourquoi certaines contraintes existent et participer à la définition des priorités. Mais cette souveraineté n’est pas la dictature de la demande individuelle. Elle consiste à construire des règles de choix explicites : quels usages doivent être fluides pour tous ? Quels besoins peuvent relever d’une configuration avancée ? Quelles exceptions justifient un traitement spécifique ?
Dans cette perspective, la friction productive a aussi sa place. Tout ne doit pas être instantané. Certaines confirmations protègent des erreurs ; certaines restrictions garantissent la cohérence des données ; certaines étapes imposent une vérification utile. La question n’est pas d’éliminer toute friction, mais de distinguer celle qui protège le travail de celle qui résulte d’une mauvaise conception.
Faire des power users des passeurs, pas des souverains
Les meilleurs utilisateurs avancés ne sont pas ceux qui gardent pour eux leurs astuces ou imposent leurs préférences. Ce sont ceux qui savent décrire ce que les autres ne voient pas encore, tout en restant attentifs à ce qu’eux-mêmes ne voient plus. Leur expertise devient alors un bien commun : elle aide à simplifier, à former, à tester et à mettre en évidence les dépendances dangereuses.
Pour une organisation, la bonne ambition n’est donc pas de fabriquer davantage de power users afin que chacun survive à la complexité. C’est de concevoir des outils suffisamment clairs pour que l’expertise soit un choix, non une condition d’entrée. Les utilisateurs avancés y gardent toute leur valeur : ils explorent les marges, inventent des usages, repoussent les limites. Mais ils cessent de décider seuls de la forme du quotidien.
Car un outil vraiment réussi ne se mesure pas seulement à ce que ses virtuoses parviennent à en tirer. Il se reconnaît à ce qu’il permet aux autres de faire, sans bruit, sans détour et sans demander la permission à l’expert du coin.
