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 ».

L’offre crée sa propre demande

Cette for­mule de Keynes résume l’idée que la demande n’est pas sta­tique et tend au contraire à aug­men­ter lorsque l’offre croît elle aus­si. La rai­son est simple : si un domaine est en situa­tion de pénu­rie, une par­tie de la demande va res­ter inex­pri­mée. Par exemple, je ne vais même pas essayer d’emprunter une route si je sais qu’elle est en per­ma­nence bou­chée. Cela ne veut pas dire que je n’en ai pas envie. Ce phé­no­mène a été redé­cou­vert, avec des variantes, dans bien des domaines :

  • Mon exemple est un pro­blème de pla­ni­fi­ca­tion des réseaux de trans­port. On y trouve le concept de demande induite (ou latente), la conjec­ture de Lewis-Mogridge et le para­doxe de Braess.
  • L’effet de rebond en éco­no­mie : aug­men­ter l’efficacité des méthodes de consom­ma­tions d’une res­source natu­relle tend à en aug­men­ter la demande. Par exemple, l’invention du moteur à vapeur de Watt, net­te­ment plus effi­cace que ses pré­dé­ces­seurs, a lar­ge­ment aug­men­té la demande en char­bon, alors que le volume néces­saire à l’industrie avait tech­ni­que­ment dimi­nué.
  • Le prin­cipe de Blynn, en image de syn­thèse : la puis­sance crois­sante des ordi­na­teurs s’est réper­cu­tée dans une aug­men­ta­tion de la qua­li­té des images, pas dans une dimi­nu­tion des temps de ren­du. Le prin­cipe de Wirth, plus géné­ral, peut aus­si être inter­pré­té dans ce sens.
  • Le prin­cipe de Parkinson : dans une orga­ni­sa­tion, le temps néces­saire pour accom­plir une tâche aug­mente jusqu’à occu­per toute la durée qu’on lui a attri­bué.

Je tiens à remer­cier la sec­tion « voir aus­si » de Wikipédia, sans qui je n’aurais pas décou­vert la moi­tié de ces idées.

Le Principe de robustesse

Dans le domaine des pro­to­coles de com­mu­ni­ca­tion, le Principe de robus­tesse veut qu’un nœud d’un réseau (par exemple un ser­veur sur Internet) soit tolé­rant quand il décide d’accepter ou non un mes­sage plus ou moins bien for­mé, et qu’il soit plus rigou­reux sur la qua­li­té des mes­sages qu’il envoie. Le prin­cipe voit son ori­gine dans les débats autour de l’importance qu’il faut don­ner à une norme de com­mu­ni­ca­tion : la stra­té­gie opti­male pour la robus­tesse du réseau, ce serait de suivre la norme de près en out­put mais beau­coup moins en input.

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

Software should be writ­ten to deal with eve­ry concei­vable error.

C’est-à-dire : ren­dez votre pro­gramme robuste en le conce­vant de telle sorte à qu’il fonc­tionne avec les plus inputs les plus variés.

La rhé­to­rique dis­pose d’un couple de règles très simi­laire : les prin­cipes d’honnêteté intel­lec­tuelle et de cha­ri­té. Le pre­mier revient à dire qu’il faut faci­li­ter le tra­vail de com­pré­hen­sion de l’interlocuteur, le second qu’il faut inter­pré­ter ses pro­pos de la manière la plus avan­ta­geuse pos­sible. (Note : c’est une vision à mini­ma. L’honnêteté intel­lec­tuelle ne se limite pas à un sou­ci de clar­té. De manière plus dras­tique, ces prin­cipes rap­pellent qu’il faut veiller à avoir un lan­gage et des valeurs de dis­cus­sion com­muns.)

Il y a un troi­sième domaine où ce prin­cipe peut s’appliquer : les IHM. La mani­pu­la­tion d’un pro­gramme peut être vue comme un dia­logue : l’utilisateur demande quelque chose et le sys­tème répond qu’il a bien effec­tué (ou non) la tâche, tout ceci via le lan­guage de l’interface. La méta­phore a notam­ment été déve­lop­pée par Hutchins dès 1987 (article en lien ici – PDF pour­rave mais réflexion pas­sion­nante), qui en note aus­si les limites : elle sup­pose qu’il y a une média­tion de type sym­bo­lique entre l’homme et la machine, avec toute la com­plexi­té et l’ambiguïté que cela implique.

Pourtant, cette méta­phore de la conver­sion s’applique encore à bien des cas, par exemple la com­plé­tion d’un for­mu­laire : j’entre une date et le pro­gramme me répond si elle a bien été com­prise. Une bonne inter­face est tolé­rante dans les for­mats pos­sibles qu’elle admet en entrée et rigou­reuse (cohé­rente) à chaque fois qu’elle doit affi­cher une date en sor­tie.

Le prin­cipe de robus­tesse sur Wikipedia

Methodes Agile et conception d’objets

Un article inté­res­sant d’Internet Actu sur l’application des méthodes Agile au génie indus­triel. Quelques remarques :

  • Cela fait fait beau­coup pen­ser à l’approche de Space X pour faire avan­cer l’exploration spa­tiale pri­vée : au lieu de lan­cer peu de fusées après des pro­cé­dures de qua­li­té extre­me­ment lourdes, il vaut mieux ité­rer sou­vent. Cela per­met d’abaisser les coûts et, para­doxa­le­ment, d’augmenter à terme la fia­bi­li­té des vols. Cf. cette décla­ra­tion : « I want to make mis­takes on a small scale and not a large one » (tirée de cet entre­tien), ou encore cet article décri­vant l’insistance sur la sim­pli­ci­té dans la concep­tion de la fusée.
  • On peut rap­pe­ler que beau­coup de termes et de concepts de la ges­tion de pro­jet viennent à l’origine des BTP : cahier des charges, maitre d’œuvre, etc. La boucle est bou­clée, en quelque sorte.
  • L’article manque un peu de mise en pers­pec­tive : le totoy­tisme / lean manu­fac­tu­ring et l’utilisation de kan­ban sont des pra­tiques éta­blies dans l’industrie et n’ont pas atten­du la mode de l’Agile.
  • Ceci étant, l’Agile se prête par­ti­cu­liè­re­ment au déve­lop­pe­ment de logi­ciel. Par exemple, Facebook peut mettre en place une nou­velle ver­sion de son site auprès de mil­lions d’utilisateurs, sans qu’ils aient de mise a jour à faire. Cela pose des pro­blèmes d’acceptation de la part des uti­li­sa­teurs et de déploie­ment, mais c’est pos­sible, et tou­jours plus facile que de vendre un nou­veau modèle de voi­ture. Il serait donc inté­res­sant de voir les pro­blèmes par­ti­cu­liers que pose l’application des méthodes Agile à la concep­tion et à la vente de biens. Pour une dis­cus­sion sur une pos­sible mon­tée en force des star­tups de hard­ware, voir ici.

Un exemple de fantasme sur le numérique

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

« Soyez authen­ti­que­ment numé­rique. Détails et appa­rence doivent décou­ler de leurs fonc­tions au lieu d’essayer d’imiter des choses réelles, telles qu’une ani­ma­tion lorsqu’on tourne la page d’un ebook. »

Ce prin­cipe part d’une bonne inten­tion : pré­fé­rer la sim­pli­ci­té au kitsch. Pourtant, « authen­ti­que­ment numé­rique », ça ne veut rien dire. En soi, « le numé­rique » n’est por­teur d’aucune iden­ti­té gra­phique. Il peut y avoir des modes ou des ten­dances (Metro, récem­ment), cer­taines contraintes tech­niques peuvent créer un style par­ti­cu­lier (les écrans de ter­mi­naux vert avec un effet de réma­nence), mais « le numé­rique » n’est rien d’autre qu’une manière de sto­cker et trans­mettre de l’information de manière dis­crète. Exemple : des signaux de fumée. Autre exemple : l’alphabet.

Couplé à un trai­te­ment auto­ma­ti­sé des don­nées, ça a bou­le­ver­sé deux ou trois choses dans notre socié­té, mais du point de vue gra­phique et inter­ac­tif, ç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égra­dés ou d’animations dans une inter­face. Il suf­fit de par­ler de fonc­tion­na­lisme ou de mini­ma­lisme.

Si on charge trop cette tech­no­lo­gie en cher­chant une hypo­thé­tique essence du numé­rique, on risque de réduire le poten­tiel expres­sif d’une inter­face gra­phique à une peau de cha­grin. Puisque rien n’est « authen­ti­que­ment numé­rique », on abou­tit vite à des visuels très aus­tères. Par exemple, cet aya­tol­lah de l’anti-skeuomorphisme a créé un plu­gin pour Mac OS cen­sé le rendre moins kitsch. Non seule­ment il fait dis­pa­raitre 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 sup­prime aus­si le motif en lin à l’arrière-plan de Mission Control (pré­sent éga­le­ment dans les dos­siers de Launchpad ain­si que dans iOS). Et là, je dis non. D’une, il était joli, sub­til et ne fai­sait de mal à per­sonne. De deux, ce n’était pas du skeuo­mor­phisme à pro­pre­ment par­ler : contrai­re­ment à la K7 dans l’application de Podcasts sur iPhone, elle ne ren­voie à aucune tech­nique ancienne deve­nue inutile. De trois, si on conti­nue dans cette logique rigo­riste beau­coup de choses peuvent être consi­dé­rées comme de simples orne­ments : les icônes en haute réso­lu­tion, les écrans cou­leur, les inter­faces gra­phique en vec­to­riel, les inter­faces gra­phiques tout court, etc.

Ce qui m’amène à mon der­nier point : en arrê­tant d’invoquer le numé­rique à tout bout de champ, on pour­ra com­men­cer à se poser de meilleures ques­tions. Notamment, tout le monde est d’accord pour dire qu’il faut se concen­trer sur les fonc­tions prin­ci­pales du logi­ciel, mais où finit le fonc­tion­nel et où com­mence le cos­mé­tique ? Par exemple, le motif en lin cité plus haut n’apporte aucune fonc­tion­na­li­té réelle, mais il peut aider à dis­tin­guer l’avant-plan du fond, tout en étant plus repo­sant pour les yeux qu’une cou­leur unie. Ou encore, des marges suf­fi­sam­ment larges ne sont pas là (uni­que­ment) pour faire clas­sieux, elles per­mettent au lec­teur de mieux dis­tin­guer le corps du texte de son envi­ron­ne­ment et de faci­li­ter le pas­sage d’une ligne à l’autre.

Bref. « le numé­rique », ça peut être n’importe quoi. S’il faut abso­lu­ment par­tir dans de grandes géné­ra­li­tés, c’en serait presque une bonne défi­ni­tion. Si vous cher­chez des guides pour conce­voir une appli­ca­tion, ou si vous vous deman­dez si la méta­phore que vous employez est kitsch ou sim­ple­ment accueillante (par exemple ici, les­quelles sont accep­tables ?), il faut cher­cher ailleurs.