Méta : Ce billet d'humeur est un peu un test : je me suis donné un temps limité pour écrire, avec interdiction de m'éterniser dessus, pour voir ce que ça donne en termes de longueur. J'ai pris un sujet qui traînait depuis longtemps dans ma TOBLOG-list (ou TORANT-list, peut-être plutôt), je ne sais pas s'il est vraiment passionnant, mais on va faire avec.
Pour communiquer des documents pédagogique à nos élèves, Télécom Paris met à la disposition des enseignants un outil (enfin, un site Web, une webapplication) appelé Moodle qui est censé nous simplifier la vie : pour rendre un document public (par exemple des notes de cours), il suffit en principe de se connecter au site et au cours visé, de cliquer sur deux-trois trucs, uploader le document, et hop, les étudiants pourront le voir. Pareil, si on veut écrire un petit texte explicatif, on peut le saisir directement dans un outil graphique qui permet de mettre du gras, de l'italique, de créer des liens, ce genre de choses, sans avoir à taper du HTML. C'est censé être plus facile pour tout le monde.
Je donne cet exemple précis, mais le phénomène est universel depuis 30–40 ans en informatique : tout outil, tout programme, un tant soit peu grand public, doit prendre la forme d'un « cliquodrome » (tiens, ce mot n'existe apparemment qu'en français), c'est-à-dire un outil tellement simple qu'il puisse être utilisé par Monsieur Toutlemonde, sans avoir à taper des commandes ou éditer des fichiers.
Alors je ne nie pas que les interfaces graphiques puissent avoir leur intérêt[], et je ne nie certainement pas qu'une interface texte puisse être complètement merdique, mais dans beaucoup de cas je trouve que vouloir à tout prix une interface graphique est une fausse bonne idée et qu'on perd plus de temps à s'en servir qu'à apprendre un outil textuel.
[] Voici quelques éléments qui justifient qu'une interface graphique puisse se justifier à mes yeux : quand les personnes qui s'en servent ne s'en serviront pas souvent (notamment si beaucoup la découvrent pour la première fois) et n'ont aucune chance d'avoir des tâches répétitives à faire avec ; et quand la tâche est intrinsèquement graphique. Je ne me plains pas, par exemple, que la borne de commande de MacDonald's soit une interface graphique !
Dans le cas de notre Moodle, par exemple, si j'ai plein de
documents à mettre en ligne d'un coup, je me retrouve à faire toute
une petite danse idiote pour chacun de ces documents : cliquer
sur ajouter une activité ou ressource
, sélectionner le
type fichier
, lui donner un nom (qui est généralement un
copier-collé du précédent avec un truc ou deux à changer), cliquer
sur déposer des fichiers
, prendre la sous-option déposer un
fichier
(parce qu'il y a plein d'autres options pour les fichiers
partagés, ou déjà déposés sur le site ou que sais-je encore),
recliquer encore sur le bouton déposer
, choisir le fichier dans
l'interface graphique de mon navigateur, cliquer une énième fois
sur déposer
(pour confirmer le dépôt), puis sur enregistrer
et revenir au cours
, et encore, je vais sans doute me rendre
compte que le fichier n'est pas apparu au bon endroit et que je dois
glisser pour le replacer ailleurs, que le glisser-déplacé marche mal
dans le navigateur ; et je dois recommencer tout ça pour le document
suivant. S'il y a juste un document ou deux à déposer, ce n'est pas
trop pénible : si on veut en mettre vingt d'un coup, c'est vraiment
fastidieux. Et si je veux ajouter une petite description sur chaque
document avec, par exemple, un bout de texte écrit en gras, je vais
devoir jouer au copier-coller (revenir au document précédent,
sélectionner la description utilisée la dernière fois), me refarcir la
mise en gras (parce qu'évidemment elle passe mal au copier-coller) à
chaque fois.
Et ce n'est pas tout : quand on doit accomplir ce genre de tâches répétitives, on prend vite des réflexes procéduraux sur l'endroit où cliquer dans la partie répétitive. Mais les interfaces graphiques sont souvent mal conçues pour ça : le truc affiché peut souvent changer pour des raisons triviales (l'outil a décidé que vous utilisiez souvent telle fonction, donc il décide de vous la montrer en premier en pensant vous faire gagner du temps… ou le navigateur a changé un peu de taille, ou un texte déborde d'une ligne sur une autre… manque de chance, ça change toute la disposition et du coup ça casse l'habitude que vous pensiez avoir prise).
Voici donc une première raison de ne pas aimer les interfaces graphiques : elles simplifient peut-être les manipulations uniques pour les débutants, mais en contrepartie, elles compliquent les manipulations répétitives en rendant l'automatisation quasi impossible.
Or c'est un fait que les ordinateurs sont souvent associés à des tâches répétitives, et ce, de façon ambivalente : d'un côté ils devraient nous simplifier leur automatisation (c'est bien le but !), mais de l'autre, ils sont souvent la source même des choses répétitives que nous devons faire.
Quand je dois réaliser une tâche répétitive sur une ligne de
commande Unix, je sais faire : j'ai plein d'outils à ma disposition
pour répéter la même chose de façon efficace ; même sans aller jusqu'à
écrire un vrai programme (script) qui répète la commande, simplement
la préparer dans un éditeur de texte, faire du recherche-remplacement
ou saisir rapidement les modifications au clavier, ou utiliser des
macros de l'éditeur, pour finalement recopier l'ensemble des lignes de
commande qu'on aura préparées, tout ça va extrêmement vite. Donc si
je pouvais utiliser une commande du genre
(j'invente complètement la syntaxe) pour chaque valeur
de moodle --course-id
foobar --section 2 --add-activity --type file --name "Corrigé du
contrôle ${year}" --upload-file corrige-${year}.pdf${year}, ce serait beaucoup plus efficace pour moi que
de devoir me battre avec une interface graphique censée me
« simplifier » la vie. Oui, une telle ligne est un peu compliquée à
préparer une fois, mais l'intérêt est qu'une fois qu'on sait
ce dont on a besoin, on peut la réutiliser sans réfléchir de façon
très efficace, alors qu'avec une interface graphique il faut toujours
refaire la même danse.
(Je précise Moodle semble bien avoir des outils permettant de s'en servir en ligne de commande, mais c'est uniquement pour l'administrateur, et je ne suis pas administrateur du Moodle mis en place par mon employeur. Donc je ne pense pas que je puisse mettre à jour les sites pédagogiques de mes cours via des lignes de commande.)
Idem quand il s'agit d'éditer un fichier : oui, c'est peut-être
plus fastidieux a priori de devoir taper quelque chose du
genre
pour
mettre un bout de texte en gras, mais l'avantage du texte brut est
qu'on sait exactement comment il interagit avec l'éditeur, comment il
se comporte pour le copier-coller, ce que ça signifie de comparer des
versions du document et d'afficher les différences entre elles. Mon
éditeur a tout ce qu'il faut (notamment un système de macros puissant)
pour faciliter l'automatisation, la recherche-remplacement ou la
gestion des versions quand il s'agit d'un fichier à éditer constitué
d'une succession simple de caractères Unicode, mais dès qu'il y a des
contenus plus riches, les outils sont considérablement plus merdiques.
Et surtout, on n'a plus vraiment le choix de l'outil : si je veux
éditer un fichier texte brut, je peux choisir l'éditeur qui me plaît ;
par exemple, si je veux éditer un fichier Word, je dois utiliser Word
ou éventuellement LibreOffice, mais en tout cas mes choix sont
nettement plus limités.ceci est en <b>gras</b>
Et encore, je postule ici que j'ai affaire à des interfaces graphiques pas trop mal conçues. Mais quand il s'agit d'outils développés au sein d'une organisation, ou sous-traitées à des développeurs incompétents qui n'ont aucune notion des bonnes pratiques en interfaces homme-machine, c'est plutôt la petite boutique des horreurs. Je n'ai pas tant à me plaindre de l'interface de Moodle en elle-même, qui n'est pas catastrophique en tant qu'interface graphique, mais celles qui nous servent à, par exemple, déclarer nos jours de congés (ou, pire, à alimenter notre compte épargne-temps), à ouvrir un ticket de maintenance auprès des services logistiques, à déclarer nos activités d'enseignement, etc., sont des abominations même quand on n'a pas de tâches répétitives à accomplir dedans. Parce que, oui, ça fait aussi partie du problème des interfaces graphiques qu'elles sont difficiles à programmer, et que quand c'est mal fait ça peut être une abomination.
Mais il n'y a pas que la réalisation des tâches répétitives que l'interface graphique rend pénible. Il y a encore au moins deux autres choses que je dois mentionner.
D'abord, la sauvegarde de l'état complet et l'examen de celui-ci. Je veux dire que quand j'interagis avec un programme via des lignes de commande et des fichiers texte de configuration, je peux normalement (enfin, je devrais pouvoir) compter sur le fait que ces lignes de commande et fichiers sont la totalité de ce qui détermine le comportement du programme. Dans une interface graphique, il est impossible de voir tout l'état à la fois, et souvent impossible de le sauvegarder de façon décente. Si j'ai un problème, je dois chercher les réglages dans tous les menus et tous-menus (il n'y a souvent pas d'outil de recherche du texte dans les menus) ; si je veux communiquer à quelqu'un d'autre tous les changements de réglages que j'ai faits, je dois les examiner à la main ou lui envoyer des captures d'écran effectuées laborieusement, au lieu de pouvoir envoyer un fichier de configuration unifié. Si je veux sauvegarder une configuration dont je suis content pour pouvoir éventuellement y revenir plus tard, je n'ai pas d'autre choix que de noter manuellement tous les réglages que j'ai faits. Ne parlons pas de quelque chose comme « trouver tous les changements que j'ai faits entre <telle date> et <telle date> ». Tout ça est tellement (inutilement) fastidieux ! D'autant que les ordinateurs sont justement censés nous simplifier ce genre de choses.
Et je ne parle même pas du fait que les interfaces graphiques ont
tendance à avoir un état opaque, unique, dont on ne sait jamais très
bien quelles manipulations vont l'affecter de façon permanente
(parfois il y a un bouton annuler
, mais on ne sait jamais vers
quoi il revient) : pas possible d'ouvrir un état secondaire, pour
tester, et revenir à l'état principal si on n'est pas content du test.
Si on fait un changement dans les réglages, paf, il est effectif
immédiatement, on n'a pas de « mode de test », de possibilité
d'annuler en bloc ou quoi que ce soit du genre.
Enfin, il y a un autre aspect qui me semble très important et rarement discuté : dans une interface textuelle (lignes de commande ou fichiers de configuration), il y a toujours moyen de commenter ce qu'on fait, pour expliquer à soi-même (ou à d'autres avec qui on collabore) pourquoi on a modifié ce réglage, pourquoi on a fait ce choix, pourquoi il ne faut pas y toucher, ce genre de choses. Les commentaires sont une méta-information cruciale. Les interfaces graphiques ne permettent pas de laisser des commentaires sur ce qu'on fait. (Pas que ce soit structuralement impossible, certes, on pourrait très bien imaginer une interface graphique qui permette d'ajouter des commentaires sur chacun de ses propres réglages, de rechercher dedans, etc. Mais en pratique, je n'ai jamais vu ça, et même s'il y a peut-être quelques outils où ça existe, le problème des interfaces graphiques est aussi qu'elles sont idiosyncratiques : chaque outil a la sienne, donc il faudrait redévelopper ça N fois. Les fichiers de configuration, par contraste, ont plein de conventions sur les commentaires, mais on peut être quasi certain que chacun a une façon d'en mettre.)
L'idéal, évidemment, c'est quand un même outil peut être utilisé à
la fois de façon graphique (pour ceux qui veulent s'en servir
rapidement et sans apprendre) et de façon textuelle, et surtout, que
le pont entre les deux façons de s'en servir est bien fait : qu'à
chaque fois qu'on en a un usage graphique, il va expliquer comment on
aurait pu produire le même résultat en ligne de commande (ou en
éditant un fichier), que les commentaires ajoutés dans un fichier de
configuration textuel sont affichés dans la version graphique, sont
préservés par la modification dans l'interface graphique mais
peut-être avec un commentaire supplémentaire modifié dans
l'interface graphique à <telle date>
, bref, c'est l'idéal,
mais à condition que ce soit bien fait, et je ne connais en gros pas
un seul exemple de cas où ce soit bien fait.
Alors oui, c'est tellement à la mode (depuis ~40 ans, hein… je ne parle pas d'une mode récente) de dire que c'est aux ordinateurs de s'adapter aux humains et pas le contraire, et qu'on va faire des trucs simples et utilisables par tout le monde, mais en fait je pense que c'est une forme de populisme d'essayer de rentre les outils (faussement) intuitifs avec des interfaces graphiques partout, et que la perte de productivité à cause de cette fausse bonne idée a été colossale, sans compter l'idée désastreuse qu'il n'y a pas besoin d'apprendre l'informatique quand on ne va pas travailler en informatique.
Tout le monde, un jour ou un autre, aura une tâche répétitive à accomplir sur un ordinateur. Si pour faire 50 fois la même chose votre interface vous oblige à répéter 50 fois les mêmes gestes, votre interface est une merde. Et c'est probablement le cas.