Contexte et motivation

Le développeur de ActivityBot constate que la plupart des documentations techniques restent des collections de notes incomplètes, souvent obsolètes, et que les utilisateurs finaux se retrouvent à poser les mêmes questions sur des forums. Dans le cadre d’une demande de subvention NLnet, il décide de vérifier l’hypothèse selon laquelle une lecture attentive du README par des personnes extérieures permettrait d’identifier les points de friction. L’objectif est de transformer le texte d’installation en une procédure réellement exécutable sans ambiguïté.

Méthodologie de test utilisateur

Le processus débute par une annonce sur Mastodon, suivie de la sélection de volontaires. Chaque participant reçoit 25 € pour une heure d’interaction en visioconférence. Le testeur partage son écran, lit le README à haute voix et décrit chaque action, les doutes et les moments de satisfaction. L’auteur prend des notes manuscrites afin d’éviter d’alimenter le processus avec un outil automatisé. Au total, 150 € sont versés, ce qui correspond à environ six sessions d’une heure chacune. Après chaque session, le README est révisé immédiatement, puis le même ou un nouveau participant le re‑teste, créant ainsi une boucle itérative de validation.

Résultats concrets et itérations

Les sessions révèlent plusieurs erreurs structurales et de forme : le lien vers l’outil de démonstration était incorrect, certains utilisateurs lisent le README directement dans le terminal et se demandent comment renommer un fichier caché, la décision de placer l’outil de démonstration en ligne ou localement n’est pas explicitée, et les règles de citation varient d’une ligne à l’autre. Les blagues insérées dans le texte sont perçues comme source de confusion, la terminologie technique nécessite des définitions, l’ordre des sections ne suit pas une logique d’utilisation, et aucune description claire du rôle du logiciel n’est fournie. De plus, les différences de gestion des permissions entre serveurs web provoquent des incompréhensions. Chaque point identifié conduit à une modification du README, suivie d’un nouveau test. Le résultat final est un document qui, bien que non parfait, montre une amélioration mesurable de la compréhension et de la réussite de l’installation.

Limites et perspectives

Cette approche reste coûteuse et dépend de la disponibilité de participants prêts à être rémunérés. Elle ne garantit pas l’exhaustivité : un petit panel ne représente pas la diversité complète des environnements utilisateurs. L’auteur reconnaît que les modèles de langage large (LLM) pourraient simuler des scénarios, mais ils ne reproduisent pas les signaux vocaux de frustration qui indiquent une erreur de conception. À l’avenir, il envisage d’associer ces tests humains à des scripts d’automatisation qui valident les chemins critiques, tout en conservant le « think‑aloud » pour les aspects ergonomiques. Cette combinaison pourrait réduire les coûts tout en conservant la richesse des retours qualitatifs.

try { await navigator.share({url:u}); } catch { alert('Copied URL to clipboard'); }