De quelques similitudes entre utilisabilité et sécurité

Créer un sys­tème, c’est s’assurer qu’il rem­plit un ensemble de fonc­tions don­nées, mais aus­si qu’il pos­sède des qua­li­tés glo­bales comme la main­te­na­bi­li­té, la fia­bi­li­té, la rapi­di­té… On les appelle par­fois des exi­gences non-fonctionnelles. Parmi elles, l’utilisabilité et la sécu­ri­té sont des qua­li­tés cru­ciales et moins anta­go­nistes que l’on ne pour­rait le croire.

Ne pas raisonner dans l’absolu

On se demande sou­vent « est-ce que cette inter­face est ergo­no­mique ? » Ce n’est pas la bonne ques­tion à se poser car elle n’a pas grand sens dans l’absolu. Il faut plu­tôt cher­cher à savoir dans quelle mesure elle est uti­li­sable, selon cer­tains cri­tères, pour cer­tains usages et avec cer­taines contraintes.

Le même enjeu existe en sécu­ri­té : on oscille entre fan­tasmes de pro­tec­tion totale et sen­ti­ment rési­gné que, de toute façon, Google et la NSA savent tout de nous. Pourtant, non seule­ment la sécu­ri­té n’est pas une pro­prié­té binaire, mais gros­so modo elle dépend de trois fac­teurs.

  1. Les enjeux : à quel point les don­nées à pro­té­ger sont cri­tiques ? Cette éva­lua­tion se fait clas­si­que­ment selon trois cri­tères : la dis­po­ni­bi­li­té (les per­sonnes auto­ri­sées ont accès aux don­nées), la confi­den­tia­li­té (uni­que­ment ces per­sonnes y ont accès) et l’intégrité (les don­nées n’ont pas été modi­fiées dans leurs dos). Selon le contexte, cer­tains cri­tères vont être pri­vi­lé­giés : par exemple je consi­dère que déver­rouiller mon télé­phone faci­le­ment est plus impor­tant que de le rendre indé­chif­frable, donc je ne lui donne pas de mot de passe inter­mi­nable.
  2. Le modèle de menace : qui en a après mes don­nées, quelles res­sources a-t-il et à quel point est-il déter­mi­né.
  3. La réponse : quelles mesures mettre en place ?

Elaborer une poli­tique de sécu­ri­té n’est pas for­cé­ment très com­pli­qué. Par exemple, selon James Mickens dans cet article très drôle, le modèle de menaces d’un par­ti­cu­lier peut se limi­ter à « Mossad ou pas Mossad ». Si le Mossad (ou une ins­ti­tu­tion com­pa­rable) en a après vous, vous êtes fou­tus. Si non, pre­nez des mesures rai­son­nables et tout ira bien.

Même si elle n’est pas très com­pli­quée, la sécu­ri­té n’est jamais une pro­prié­té binaire. Il en va de même en ergo­no­mie : on peut favo­ri­ser la poly­va­lence ou la spé­cia­li­sa­tion, une appre­na­bi­li­té rapide ou longue, etc.

Ne pas se croire tout puissant

En sécu­ri­té, un aspect inté­res­sant est que les mesures prises ont pour objec­tifs de rendre accep­table le niveau de risque — et pas plus. Pour chaque risque iden­ti­fié, on éva­lue sa vrai­sem­blance et sa gra­vi­té, avant de prendre une mesure pour dimi­nuer son impact. A la fin, il reste des vul­né­ra­bi­li­tés rési­duelles, qu’il suf­fit d’expliciter et de jus­ti­fier : certes, quelqu’un avec un accès phy­sique au sys­tème, une porte déro­bée déjà en place et un super­cal­cu­la­teur de poche pour­rait opé­rer une brèche. Mais c’est un risque accep­table.

Ce n’est pas très dif­fé­rent d’une démarche ergo, dans laquelle on iden­ti­fie cer­tains déter­mi­nants de l’activité (par exemple, l’utilisateur est for­cé d’utiliser sa tablette avec des moufles), aux­quels on répond par des solu­tions (dou­bler la taille des bou­tons) ou des recom­man­da­tions (ne pas uti­li­ser la tablette dans un contexte néces­si­tant ces moufles).

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

  • Moins for­ma­li­sée : Les obser­va­tions et solu­tions sont moins décom­po­sées, les points faibles sont affi­chés de manière moins trans­pa­rente. (Mais j’ai peut-être une vision idéa­liste des audits de sécu­ri­té.)
  • Moins cadrée : au nom d’une uti­li­sa­bi­li­té par­faite et abso­lue, on nous demande sou­vent l’impossible. Une bonne part du bou­lot d’un expert en ergo­no­mie est d’expliquer que l’on n’est pas omni­po­tents.

Faire avec l’utilisateur

Une der­nière simi­li­tude, c’est qu’on ne peut pas conce­voir un sys­tème iso­lé : il faut anti­ci­per son uti­li­sa­tion et sup­po­ser que l’utilisateur peut être étour­di, bri­co­leur, ou mal­veillant (voire les trois en même temp). Par exemple, il faut anti­ci­per ce qui se passe si l’utilisateur oublie son mot de passe ou s’il est laxiste dans une pro­cé­dure de véri­fi­ca­tion quel­conque.

Dans les deux cas, il y a une ten­sion entre les uti­li­sa­teurs réels (pres­sés et tous dif­fé­rents) et idéaux (conscien­cieux et atten­tifs). Il existe même un concept juri­dique de « per­sonne pru­dente et rai­son­nable », consa­crant le fait que mani­pu­ler des infor­ma­tions sen­sibles entraine cer­taines res­pon­sa­bi­li­tés et exige un cer­tain com­por­te­ment. Evidemment, c’est plu­tôt rare d’aller en pri­son parce que vous n’avez pas uti­li­sé un logi­ciel comme un concep­teur l’espérait. Malgré tout, la concep­tion doit faire cer­tains pos­tu­lats et com­pro­mis.

Similaires, voire complémentaires

La sécu­ri­té nuit sou­vent tel­le­ment à l’utilisabilité qu’elle se tire une balle dans le pied. Les exemples ne manquent pas, des cri­tères absurdes de choix de mot de passe à la com­plexi­té (PDF) des outils de chif­fre­ment. Les deux approches sont suf­fi­sam­ment simi­laires pour pou­voir être com­plé­men­taires. Il suf­fit d’en reve­nir à l’utilisateur. Voici deux articles clas­siques pour creu­ser le sujet : « Users are not the ene­my  » (PDF) et « When secu­ri­ty gets in the way ».