De quelques similitudes entre utilisabilité et sécurité

Créer un système, c’est s’assurer qu’il remplit un ensemble de fonctions données, mais aussi qu’il possède des qualités globales comme la maintenabilité, la fiabilité, la rapidité… On les appelle parfois des exigences non-fonctionnelles. Parmi elles, l’utilisabilité et la sécurité sont des qualités cruciales et moins antagonistes que l’on ne pourrait le croire.

Ne pas raisonner dans l’absolu

On se demande souvent « est-ce que cette interface est ergonomique ? » Ce n’est pas la bonne question à se poser car elle n’a pas grand sens dans l’absolu. Il faut plutôt chercher à savoir dans quelle mesure elle est utilisable, selon certains critères, pour certains usages et avec certaines contraintes.

Le même enjeu existe en sécurité : on oscille entre fantasmes de protection totale et sentiment résigné que, de toute façon, Google et la NSA savent tout de nous. Pourtant, non seulement la sécurité n’est pas une propriété binaire, mais grosso modo elle dépend de trois facteurs.

  1. Les enjeux : à quel point les données à protéger sont critiques ? Cette évaluation se fait classiquement selon trois critères : la disponibilité (les personnes autorisées ont accès aux données), la confidentialité (uniquement ces personnes y ont accès) et l’intégrité (les données n’ont pas été modifiées dans leurs dos). Selon le contexte, certains critères vont être privilégiés : par exemple je considère que déverrouiller mon téléphone facilement est plus important que de le rendre indéchiffrable, donc je ne lui donne pas de mot de passe interminable.
  2. Le modèle de menace : qui en a après mes données, quelles ressources a-t-il et à quel point est-il déterminé.
  3. La réponse : quelles mesures mettre en place ?

Elaborer une politique de sécurité n’est pas forcément très compliqué. Par exemple, selon James Mickens dans cet article très drôle, le modèle de menaces d’un particulier peut se limiter à « Mossad ou pas Mossad ». Si le Mossad (ou une institution comparable) en a après vous, vous êtes foutus. Si non, prenez des mesures raisonnables et tout ira bien.

Même si elle n’est pas très compliquée, la sécurité n’est jamais une propriété binaire. Il en va de même en ergonomie : on peut favoriser la polyvalence ou la spécialisation, une apprenabilité rapide ou longue, etc.

Ne pas se croire tout puissant

En sécurité, un aspect intéressant est que les mesures prises ont pour objectifs de rendre acceptable le niveau de risque — et pas plus. Pour chaque risque identifié, on évalue sa vraisemblance et sa gravité, avant de prendre une mesure pour diminuer son impact. A la fin, il reste des vulnérabilités résiduelles, qu’il suffit d’expliciter et de justifier : certes, quelqu’un avec un accès physique au système, une porte dérobée déjà en place et un supercalculateur de poche pourrait opérer une brèche. Mais c’est un risque acceptable.

Ce n’est pas très différent d’une démarche ergo, dans laquelle on identifie certains déterminants de l’activité (par exemple, l’utilisateur est forcé d’utiliser sa tablette avec des moufles), auxquels on répond par des solutions (doubler la taille des boutons) ou des recommandations (ne pas utiliser la tablette dans un contexte nécessitant ces moufles).

La différence, dans mon expérience, c’est que la démarche ergo est :

  • Moins formalisée : Les observations et solutions sont moins décomposées, les points faibles sont affichés de manière moins transparente. (Mais j’ai peut-être une vision idéaliste des audits de sécurité.)
  • Moins cadrée : au nom d’une utilisabilité parfaite et absolue, on nous demande souvent l’impossible. Une bonne part du boulot d’un expert en ergonomie est d’expliquer que l’on n’est pas omnipotents.

Faire avec l’utilisateur

Une dernière similitude, c’est qu’on ne peut pas concevoir un système isolé : il faut anticiper son utilisation et supposer que l’utilisateur peut être étourdi, bricoleur, ou malveillant (voire les trois en même temp). Par exemple, il faut anticiper ce qui se passe si l’utilisateur oublie son mot de passe ou s’il est laxiste dans une procédure de vérification quelconque.

Dans les deux cas, il y a une tension entre les utilisateurs réels (pressés et tous différents) et idéaux (consciencieux et attentifs). Il existe même un concept juridique de « personne prudente et raisonnable », consacrant le fait que manipuler des informations sensibles entraine certaines responsabilités et exige un certain comportement. Evidemment, c’est plutôt rare d’aller en prison parce que vous n’avez pas utilisé un logiciel comme un concepteur l’espérait. Malgré tout, la conception doit faire certains postulats et compromis.

Similaires, voire complémentaires

La sécurité nuit souvent tellement à l’utilisabilité qu’elle se tire une balle dans le pied. Les exemples ne manquent pas, des critères absurdes de choix de mot de passe à la complexité (PDF) des outils de chiffrement. Les deux approches sont suffisamment similaires pour pouvoir être complémentaires. Il suffit d’en revenir à l’utilisateur. Voici deux articles classiques pour creuser le sujet : « Users are not the enemy  » (PDF) et « When security gets in the way ».

L’offre crée sa propre demande

Cette formule de Keynes résume l’idée que la demande n’est pas statique et tend au contraire à augmenter lorsque l’offre croît elle aussi. La raison est simple : si un domaine est en situation de pénurie, une partie de la demande va rester inexprimée. Par exemple, je ne vais même pas essayer d’emprunter une route si je sais qu’elle est en permanence bouchée. Cela ne veut pas dire que je n’en ai pas envie. Ce phénomène a été redécouvert, avec des variantes, dans bien des domaines :

  • Mon exemple est un problème de planification des réseaux de transport. On y trouve le concept de demande induite (ou latente), la conjecture de Lewis-Mogridge et le paradoxe de Braess.
  • L’effet de rebond en économie : augmenter l’efficacité des méthodes de consommations d’une ressource naturelle tend à en augmenter la demande. Par exemple, l’invention du moteur à vapeur de Watt, nettement plus efficace que ses prédécesseurs, a largement augmenté la demande en charbon, alors que le volume nécessaire à l’industrie avait techniquement diminué.
  • Le principe de Blynn, en image de synthèse : la puissance croissante des ordinateurs s’est répercutée dans une augmentation de la qualité des images, pas dans une diminution des temps de rendu. Le principe de Wirth, plus général, peut aussi être interprété dans ce sens.
  • Le principe de Parkinson : dans une organisation, le temps nécessaire pour accomplir une tâche augmente jusqu’à occuper toute la durée qu’on lui a attribué.

Je tiens à remercier la section « voir aussi » de Wikipédia, sans qui je n’aurais pas découvert la moitié de ces idées.

Le Principe de robustesse

Dans le domaine des protocoles de communication, le Principe de robustesse veut qu’un nœud d’un réseau (par exemple un serveur sur Internet) soit tolérant quand il décide d’accepter ou non un message plus ou moins bien formé, et qu’il soit plus rigoureux sur la qualité des messages qu’il envoie. Le principe voit son origine dans les débats autour de l’importance qu’il faut donner à une norme de communication : la stratégie optimale pour la robustesse du réseau, ce serait de suivre la norme de près en output mais beaucoup moins en input.

Par la suite (RFC 1122, § 1.2.2), il été a interprété de manière plus large comme un principe de prévoyance :

Software should be written to deal with every conceivable error.

C’est-à-dire : rendez votre programme robuste en le concevant de telle sorte à qu’il fonctionne avec les plus inputs les plus variés.

La rhétorique dispose d’un couple de règles très similaire : les principes d’honnêteté intellectuelle et de charité. Le premier revient à dire qu’il faut faciliter le travail de compréhension de l’interlocuteur, le second qu’il faut interpréter ses propos de la manière la plus avantageuse possible. (Note : c’est une vision à minima. L’honnêteté intellectuelle ne se limite pas à un souci de clarté. De manière plus drastique, ces principes rappellent qu’il faut veiller à avoir un langage et des valeurs de discussion communs.)

Il y a un troisième domaine où ce principe peut s’appliquer : les IHM. La manipulation d’un programme peut être vue comme un dialogue : l’utilisateur demande quelque chose et le système répond qu’il a bien effectué (ou non) la tâche, tout ceci via le language de l’interface. La métaphore a notamment été développée par Hutchins dès 1987 (article en lien ici – PDF pourrave mais réflexion passionnante), qui en note aussi les limites : elle suppose qu’il y a une médiation de type symbolique entre l’homme et la machine, avec toute la complexité et l’ambiguïté que cela implique.

Pourtant, cette métaphore de la conversion s’applique encore à bien des cas, par exemple la complétion d’un formulaire : j’entre une date et le programme me répond si elle a bien été comprise. Une bonne interface est tolérante dans les formats possibles qu’elle admet en entrée et rigoureuse (cohérente) à chaque fois qu’elle doit afficher une date en sortie.

Le principe de robustesse sur Wikipedia

Methodes Agile et conception d’objets

Un article intéressant d’Internet Actu sur l’application des méthodes Agile au génie industriel. Quelques remarques :

  • Cela fait fait beaucoup penser à l’approche de Space X pour faire avancer l’exploration spatiale privée : au lieu de lancer peu de fusées après des procédures de qualité extremement lourdes, il vaut mieux itérer souvent. Cela permet d’abaisser les coûts et, paradoxalement, d’augmenter à terme la fiabilité des vols. Cf. cette déclaration : « I want to make mistakes on a small scale and not a large one » (tirée de cet entretien), ou encore cet article décrivant l’insistance sur la simplicité dans la conception de la fusée.
  • On peut rappeler que beaucoup de termes et de concepts de la gestion de projet viennent à l’origine des BTP : cahier des charges, maitre d’œuvre, etc. La boucle est bouclée, en quelque sorte.
  • L’article manque un peu de mise en perspective : le totoytisme / lean manufacturing et l’utilisation de kanban sont des pratiques établies dans l’industrie et n’ont pas attendu la mode de l’Agile.
  • Ceci étant, l’Agile se prête particulièrement au développement de logiciel. Par exemple, Facebook peut mettre en place une nouvelle version de son site auprès de millions d’utilisateurs, sans qu’ils aient de mise a jour à faire. Cela pose des problèmes d’acceptation de la part des utilisateurs et de déploiement, mais c’est possible, et toujours plus facile que de vendre un nouveau modèle de voiture. Il serait donc intéressant de voir les problèmes particuliers que pose l’application des méthodes Agile à la conception et à la vente de biens. Pour une discussion sur une possible montée en force des startups de hardware, voir ici.

Un exemple de fantasme sur le numérique

Dans un article sur la conception d’applications pour Windows 8, on peut lire :

« Soyez authentiquement numérique. Détails et apparence doivent découler de leurs fonctions au lieu d’essayer d’imiter des choses réelles, telles qu’une animation lorsqu’on tourne la page d’un ebook. »

Ce principe part d’une bonne intention : préférer la simplicité au kitsch. Pourtant, « authentiquement numérique », ça ne veut rien dire. En soi, « le numérique » n’est porteur d’aucune identité graphique. Il peut y avoir des modes ou des tendances (Metro, récemment), certaines contraintes techniques peuvent créer un style particulier (les écrans de terminaux vert avec un effet de rémanence), mais « le numérique » n’est rien d’autre qu’une manière de stocker et transmettre de l’information de manière discrète. Exemple : des signaux de fumée. Autre exemple : l’alphabet.

Couplé à un traitement automatisé des données, ça a bouleversé deux ou trois choses dans notre société, mais du point de vue graphique et interactif, ça ne change pas grand chose. Par conséquent, c’est un peu à coté de la plaque d’invoquer le numérique quand on ne veut pas mettre de dégradés ou d’animations dans une interface. Il suffit de parler de fonctionnalisme ou de minimalisme.

Si on charge trop cette technologie en cherchant une hypothétique essence du numérique, on risque de réduire le potentiel expressif d’une interface graphique à une peau de chagrin. Puisque rien n’est « authentiquement numérique », on aboutit vite à des visuels très austères. Par exemple, cet ayatollah de l’anti-skeuomorphisme a créé un plugin pour Mac OS censé le rendre moins kitsch. Non seulement il fait disparaitre les thèmes non-standard de Contacts et de Calendar (jusqu’ici tout va bien, ce sont des skins, les skins c’est mal), mais il supprime aussi le motif en lin à l’arrière-plan de Mission Control (présent également dans les dossiers de Launchpad ainsi que dans iOS). Et là, je dis non. D’une, il était joli, subtil et ne faisait de mal à personne. De deux, ce n’était pas du skeuomorphisme à proprement parler : contrairement à la K7 dans l’application de Podcasts sur iPhone, elle ne renvoie à aucune technique ancienne devenue inutile. De trois, si on continue dans cette logique rigoriste beaucoup de choses peuvent être considérées comme de simples ornements : les icônes en haute résolution, les écrans couleur, les interfaces graphique en vectoriel, les interfaces graphiques tout court, etc.

Ce qui m’amène à mon dernier point : en arrêtant d’invoquer le numérique à tout bout de champ, on pourra commencer à se poser de meilleures questions. Notamment, tout le monde est d’accord pour dire qu’il faut se concentrer sur les fonctions principales du logiciel, mais où finit le fonctionnel et où commence le cosmétique ? Par exemple, le motif en lin cité plus haut n’apporte aucune fonctionnalité réelle, mais il peut aider à distinguer l’avant-plan du fond, tout en étant plus reposant pour les yeux qu’une couleur unie. Ou encore, des marges suffisamment larges ne sont pas là (uniquement) pour faire classieux, elles permettent au lecteur de mieux distinguer le corps du texte de son environnement et de faciliter le passage d’une ligne à l’autre.

Bref. « le numérique », ça peut être n’importe quoi. S’il faut absolument partir dans de grandes généralités, c’en serait presque une bonne définition. Si vous cherchez des guides pour concevoir une application, ou si vous vous demandez si la métaphore que vous employez est kitsch ou simplement accueillante (par exemple ici, lesquelles sont acceptables ?), il faut chercher ailleurs.