Toute la complexité du monde se cache dans le champ Nom d’un formulaire

Une personne n’a pas forcément un seul prénom suivi d’un seul nom de famille. Elle peut avoir un seul nom, ou trois prénoms et quatre noms de famille, en changer au cours de sa vie, son nom peut être très long ou très court… il y a tellement de variantes à travers les sociétés humaines que l’exception doit être considérée comme la norme. Cette complexité existe aussi pour les numéros de téléphone, les adresses, et pour tant d’autres mécanismes qu’il existe toute une littérature à ce sujet, avec un titre devenu coutumier : « Les erreurs que font les développeurs avec [bidule]».

S’il existe une longue liste de ces dispositifs, c’est qu’ils sont trop souvent mal pris en compte en informatique. Cela peut avoir des conséquences très gênantes, par exemple si votre nom de famille est aussi un mot réservé qui signifie le « rien » en programmation et que vous faites tout bugger.

C’est un problème classique d’écart entre le territoire et la carte. Un concepteur modélise la réalité comme il peut, en faisant des raccourcis : un être humain est identifié par un prénom et un nom, dans cet ordre et sans rien d’autre. Il doit bien exister deux trois exceptions mais on verra plus tard, se dit‐il.

Les noms sont déjà complexes, alors imaginez une notion comme la famille. Par exemple le service Google Play Family impose des règles qui forment une définition implicite.

Admettons que ce sont surtout des limites commerciales pensées pour que les gens n’abusent pas du système en ajoutant trois cent personnes du monde entier à leur « famille ». Mais quand même. Qui est Google pour dire qu’une famille ne peut être composée de nombreuses personnes vivant dans plusieurs pays ? Ensuite, ça influe forcément sur la vie des gens : le service devient intriqué avec leur quotidien et définit quels films peut regarder un enfant, avec qui et sur quel appareil. Tout ça dans un contexte d’objets toujours plus présents et connectés, où la famille peut avoir un appareil Google dans chaque pièce et plus d’appareils que de membre.

Nom, prénom et design tragique

Bref, concevoir un système peut avoir des conséquences graves et inattendues, c’est un thème dont la profession prend conscience, avec différents approches (design tragique, design systémique…) et spécialités (impact sur les minorités, biais et automatisation forcenée en intelligence artificielle…).

Mais ce que j’aime avec mes exemples, c’est qu’ils paraissent anodins. On ne parle pas de l’UI qui a causé l’envoi d’une fausse alerte d’attaque de missiles à tout Hawaï ou de cockpits d’avions mal conçus. La majorité des gens aujourd’hui saisissent leur nom en deux secondes et leur adresse par auto‐complétion. Pourtant les noms sont une construction à l’intersection de bien des enjeux et des institutions sociales :

Enfin et plus largement, les noms de personnes sont en eux‐même un phénomène social complexe, avec un champ d’étude dédié en sciences sociales : l’anthroponymie, dont on pourra lire une synthèse fascinante ici. Elle nous apprend qu’ils ne servent pas qu’à identifier une personne, loin de là, mais aussi à classer et hiérarchiser, à inscrire la personne dans une certaine organisation sociale et symbolique, ainsi qu’à s’adresser à elle d’une certaine manière, dans un certain contexte.

Bref, pour peu qu’on creuse un peu, toute la complexité de ce qu’on appelle un système socio‐technique peut surgir d’un modeste champ de formulaire.

Le futur sera trivial

J’aime beaucoup le concept de futur trivial (« future mundane ») de Nick Foster, qu’il a présenté dans un article et lors d’une conférence. Qu’est-ce à dire ?

Millenium Falcon

Thèse 1 : « dans le futur, les tables resteront branlantes » (source de la formule)

Comprendre : la technologie restera imparfaite, soumise à l’usure, pleine d’imprévus, et vecteur de désagréments, petits ou gros.

Thèse 2 : une société humaine change par accrétion.

  • Elle évolue selon des rythmes différenciés. Comme le suggère le schéma ci‐après, la mode change plus vite que les infrastructures.
  • Elle évolue de manière non séquentielle : une technologie n’est pas adoptée instantanément et universellement, et des technologies de génération différente peuvent cohabiter et se mélanger. Pour reprendre l’exemple favori de David Edgerton, on n’a jamais autant utilisé de chevaux que pendant les deux guerres mondiales. Je recommande d’ailleurs vivement les articles et livres de cet historien des sciences.

2016-09-29_23h49_56

On peut interpréter ce concept de plusieurs manières :

  • Pessimisme (90% des choses sont nulles et le resteront).
  • Difficulté à concevoir un système complexe en anticipant tous ses aspects. Comme le dit Frederik Pohl : « une bonne histoire de science‐fiction doit pouvoir prédire l’embouteillage et non l’automobile ».
  • L’idée que certains micro‐phénomènes sont plus révélateurs de changement que les jetpacks et autres voitures volantes.

A ce sujet, on pourra aussi lire le chapitre « Futurs au quotidien » de ce livre par Nicolas Nova – d’ailleurs un collègue de Foster.

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