Le développeur s’est levé du mauvais poil ce matin
De la même façon qu’on s’attend à un accueil poli et courtois lorsqu’on magasine, l’utilisateur devrait s’attendre à recevoir des messages d’erreurs qui ne sont pas agressifs.
En premier lieu, il y a toute la catégorie des «erreurs catastrophiques» :
Défaillance catastrophique, qu’est-ce que tu as fait?
D’abord, pourquoi c’est catastrophique? Personne n’est mort, la matériel bien souvent n’est pas abîmé.
Si l’utilisateur est un développeur, il comprendra qu’il a peut-être perdu cinq minutes de code non sauvegardé (qu’il lui prendra trois minutes à réécrire), mais quelqu’un qui n’est pas du domaine informatique pourrait penser qu’il a vraiment fait une grosse gaffe.
A une époque, les erreurs catastrophiques étaient à la mode. Un autre exemple :
Tiens, dans le domaine de l’escalade verbale, voici un beau cas :
Non seulement l’erreur est FATALE (quelqu’un est mort?), mais on l’écrit EN MAJUSCULE. La défaillance est catastrophique, et c’est à l’utilisateur de faire l’investigation (c’est sûrement sa faute). Ensuite, il faut arrêter le processus (en anglais, on dit kill, pourquoi pas simplement stop?). Et évidemment le code à la fin du message est de l’humour de programmeurs qui consiste à utiliser les six lettres de l’hexadécimal pour former un mot (0xDeadbeef, 0xCafebabe, ..).
Autre exemple:
Vous avez fait quelque-chose d’«illégal».
Dans du code ou dans une documentation technique, un caractère peut très bien être illégal, mais dans un interface utilisateur, invalide serait une meilleur mot.
Imaginez que vous développer un logiciel de gestion de personnel, qui est ensuite acheté par un cabinet d’avocats. Certains peuvent penser que les avocats sont pointilleux sur les termes, mais c’est leur travail de s’assurer que chaque mot est judicieusement choisi : un terme mal utilisé dans un contrat ou une entente peut avoir des conséquences juridiques. Ils ne seraient probablement pas contents d’utiliser un logiciel qui leur dit qu’ils ont fait une opération illégale.
Autre exemple tiré de l’IDE Visual Studio de Microsoft:
Vous pourriez CORROMPRE un élément du projet. Voulez-vous VRAIMENT faire cela?
Les mots soulignés sont forts (vous pourriez corrompre un élément du projet). De plus, la formulation Do you really want est très condescendante, comme si l’utilisateur ne comprenait pas toutes les conséquences de ce qu’il voulait faire.
Enfin, le message d’erreur classique des premiers Macintosh :
Le message d’erreur était correct (l’ordinateur est désolé) et quand ce type d’erreur se produisait, il n’y avait pas grand chose à faire à part redémarrer le système. L’icône de la bombe était toutefois inutilement catastrophique.
Les développeurs étant très majoritairement masculins (surtout au début de l’informatique), la formulation a souvent tendance à être inutilement agressive. Des termes plus neutres seraient le plus souvent plus appropriés.
| Au lieu de dire : | Pourquoi ne pas dire simplement : |
|---|---|
| Kill a process | Stop a process |
| Abort an operation | Cancel an operation |
| Shut down | Turn off |
| Illegal character | Invalid character |
| Fatal error | Major error |
La formulation de messages d’erreurs polis, en plus d’être une façon de respecter l’utilisateur, a des avantages pour le développeur de logiciel : les gens qui sont traités poliment auront tendance à être polis et plus tolérants à leur tour lorsqu’ils seront confrontés à une anomalie ou une limitation dans le logiciel.
Des messages d’erreurs agressifs rendent les utilisateurs agressifs
A lire aussi: