Il n'y a pas d'étude de l'ergonomie du client PGP GnuPG
Pas à ma connaissance en effet.
De toute façon, étudier l’ergonomie d’un outil en ligne de commande que l’utilisateur lambda n’utilise jamais directement (l’utilisateur lambda passe par un front-end graphique, standalone ou intégré à un client mail), quel intérêt ?
Ce serait comme vouloir étudier l’ergonomie d’un compilateur au lieu de celle de l’environnement de développement : quel sens y aurait-il à étudier l’ergonomie de vc.exe, c’est l’ergonomie de Visual Studio qui compte...
Tellement par ailleurs que le fait de lever la moindre critique est un blasphème.
Quand la critique est à ce point à côté de la plaque...
Citer des études de PGP ou Mailvelope pour critiquer l’utilisabilité de GnuPG, c’est à côté de la plaque pour au moins deux raisons :
PGP et Mailvelope sont des outils que l’utilisateur lambda utilise directement ; GnuPG est un backend destinés aux utilisateurs avancés (pour continuer mon exemple ci-dessus, tu cites une étude critiquant Visual Studio pour parler de l’ergonomie de GCC).
Même si PGP et GnuPG étaient tous deux des logiciels avec lesquels les utilisateurs lambdas interagissent directement, ce ne sont pas les mêmes logiciels. C’est comme si tu disais « Thunderbird est inutilisable, pour preuve voici un papier qui dit que Outlook est inutilisable. »
Je ne peux pas interpréter ça autrement que comme une volonté gratuite de cracher sur un logiciel, sans la moindre intention d’être constructif.
Tu veux être constructif ? Alors adresse tes critiques aux bonnes personnes. L’implémentation X d’OpenPGP est inutilisable ? Plains-toi aux développeurs de X au lieu de geindre que les développeurs de Y n’écoutent pas leurs utilisateurs.
Pour information et à ma connaissance, les seuls programmes graphiques (destinés à tous les utilisateurs et non pas seulement à ceux que la ligne de commande ne rebute pas) dans lesquels les développeurs de GnuPG sont plus ou moins impliqués sont :
GPA (GNU Privacy Assistant), développé (au moins en partie) par Werner Koch et Marcus Brinkmann ;
Enigmail (Kai Michaelis, un des contributeurs, est partiellement financé par g10code) ;
KMail.
Si tu as des critiques sur ces logiciels-là, tu peux te répandre et accuser les développeurs de GnuPG.
Il n'y a pas d'étude de l'ergonomie du client PGP GnuPG, un client en ligne de commande ancien (parce que, l'interface n'a probablement pas radicalement changé depuis le début).
Ancien ne veut pas dire obsolète. ET en général, on attend d’un outil en ligne de commande que son interface reste stable, surtout s’il sert de backend pour des outils plus proches de l’utilisateur.
En l'occurrence, quand dans l'étude de 2015, il y a 90% d'échec, on peut affirmer que ce n'est pas ergonomique et que ce n'est pas satisfaisant.
Mais c’est le problème des développeurs d’implémentations purement graphiques (comme PGP ou Mailvelope) ou de front-ends graphiques de GnuPG (comme Enigmail) ! GnuPG fournit le backend.
Toutefois les problèmes d’utilisabilité ne sont pas ignorés par les développeurs de GnuPG. Au contraire une grosse partie des travaux de ces dernières années (listés dans le journal) vise à améliorer l’utilisabilité pour les masses.
Un exemple : l’authentification des clefs. Tout le monde sait que la toile de confiance est trop compliquée à comprendre (encore plus à utiliser) pour le commun des mortels. Aucune interface graphique n’a jamais réussi à rendre ça intuitif, et je pense personnellement que c’est impossible.
Du coup, Neal Walfield a implémenté dans GnuPG un modèle de confiance plus simple, celui de la « confiance au premier contact ». Pour information, lors des premières discussions autour du modèle TOFU, plusieurs personnes ont fait valoir que cette fonctionnalité n’avait rien à faire dans GnuPG et que c’était plutôt le rôle des clients mails. Mais la position des développeurs de GnuPG était que TOFU serait plus utile s’il était implémenté une fois pour toutes dans le backend, plutot que de laisser chaque front-end faire sa sauce. Cette position a prévalu.
Alors certes, pour l’instant, TOFU ne change en rien la vie de l’utilisateur final. Il faut d’abord que les front-ends suivent le mouvement, et exploitent cette nouvelle fonctionnalité du backend (ce qu’aucun front-end ne fait encore à ma connaissance, à part GPA). Mais les développeurs de GnuPG ont fait leur boulot, maintenant la balle est dans le camp des développeurs de front-ends.
Pareil pour la question de la distribution des clefs. Tout est en place, dans GnuPG, pour permettre la publication et la récupération automatique d’une clef, sans aucune intervention de l’utilisateur. Maintenant il faut d’une part des front-ends qui exploitent ça, et d’autre part des fournisseurs de messagerie qui le supportent (on en trouve en Allemagne, comme posteo.de que j’avais cité dans mon précédent journal). Mais au niveau de GnuPG, la fonctionnalité est là.
Ça ne se voit peut-être pas, mais on va arriver progressivement à une situation où les messages de « Johnny » seront chiffrés sans qu’il n’ait rien à faire.
Tu peux cracher ta bile tant que tu veux, mais je réfute catégoriquement l’idée que les développeurs de GnuPG sont sourds aux remarques des utilisateurs et se moquent éperdument des questions d’utilisabilité.
[^] # Re: Et l'ergonomie de gpg, on en parle ?
Posté par gouttegd . En réponse au journal GnuPG lance une nouvelle campagne de financement. Évalué à 5.
Pas à ma connaissance en effet.
De toute façon, étudier l’ergonomie d’un outil en ligne de commande que l’utilisateur lambda n’utilise jamais directement (l’utilisateur lambda passe par un front-end graphique, standalone ou intégré à un client mail), quel intérêt ?
Ce serait comme vouloir étudier l’ergonomie d’un compilateur au lieu de celle de l’environnement de développement : quel sens y aurait-il à étudier l’ergonomie de vc.exe, c’est l’ergonomie de Visual Studio qui compte...
Quand la critique est à ce point à côté de la plaque...
Citer des études de PGP ou Mailvelope pour critiquer l’utilisabilité de GnuPG, c’est à côté de la plaque pour au moins deux raisons :
Je ne peux pas interpréter ça autrement que comme une volonté gratuite de cracher sur un logiciel, sans la moindre intention d’être constructif.
Tu veux être constructif ? Alors adresse tes critiques aux bonnes personnes. L’implémentation X d’OpenPGP est inutilisable ? Plains-toi aux développeurs de X au lieu de geindre que les développeurs de Y n’écoutent pas leurs utilisateurs.
Pour information et à ma connaissance, les seuls programmes graphiques (destinés à tous les utilisateurs et non pas seulement à ceux que la ligne de commande ne rebute pas) dans lesquels les développeurs de GnuPG sont plus ou moins impliqués sont :
Si tu as des critiques sur ces logiciels-là, tu peux te répandre et accuser les développeurs de GnuPG.
Ancien ne veut pas dire obsolète. ET en général, on attend d’un outil en ligne de commande que son interface reste stable, surtout s’il sert de backend pour des outils plus proches de l’utilisateur.
Mais c’est le problème des développeurs d’implémentations purement graphiques (comme PGP ou Mailvelope) ou de front-ends graphiques de GnuPG (comme Enigmail) ! GnuPG fournit le backend.
Toutefois les problèmes d’utilisabilité ne sont pas ignorés par les développeurs de GnuPG. Au contraire une grosse partie des travaux de ces dernières années (listés dans le journal) vise à améliorer l’utilisabilité pour les masses.
Un exemple : l’authentification des clefs. Tout le monde sait que la toile de confiance est trop compliquée à comprendre (encore plus à utiliser) pour le commun des mortels. Aucune interface graphique n’a jamais réussi à rendre ça intuitif, et je pense personnellement que c’est impossible.
Du coup, Neal Walfield a implémenté dans GnuPG un modèle de confiance plus simple, celui de la « confiance au premier contact ». Pour information, lors des premières discussions autour du modèle TOFU, plusieurs personnes ont fait valoir que cette fonctionnalité n’avait rien à faire dans GnuPG et que c’était plutôt le rôle des clients mails. Mais la position des développeurs de GnuPG était que TOFU serait plus utile s’il était implémenté une fois pour toutes dans le backend, plutot que de laisser chaque front-end faire sa sauce. Cette position a prévalu.
Alors certes, pour l’instant, TOFU ne change en rien la vie de l’utilisateur final. Il faut d’abord que les front-ends suivent le mouvement, et exploitent cette nouvelle fonctionnalité du backend (ce qu’aucun front-end ne fait encore à ma connaissance, à part GPA). Mais les développeurs de GnuPG ont fait leur boulot, maintenant la balle est dans le camp des développeurs de front-ends.
Pareil pour la question de la distribution des clefs. Tout est en place, dans GnuPG, pour permettre la publication et la récupération automatique d’une clef, sans aucune intervention de l’utilisateur. Maintenant il faut d’une part des front-ends qui exploitent ça, et d’autre part des fournisseurs de messagerie qui le supportent (on en trouve en Allemagne, comme posteo.de que j’avais cité dans mon précédent journal). Mais au niveau de GnuPG, la fonctionnalité est là.
Ça ne se voit peut-être pas, mais on va arriver progressivement à une situation où les messages de « Johnny » seront chiffrés sans qu’il n’ait rien à faire.
Tu peux cracher ta bile tant que tu veux, mais je réfute catégoriquement l’idée que les développeurs de GnuPG sont sourds aux remarques des utilisateurs et se moquent éperdument des questions d’utilisabilité.