{"id":1836,"date":"2009-09-29T16:55:00","date_gmt":"2009-09-29T16:55:00","guid":{"rendered":"http:\/\/www.nodesign.net\/blog\/admin\/wp\/?p=1836"},"modified":"2010-04-14T18:52:30","modified_gmt":"2010-04-14T18:52:30","slug":"le-design-logiciel","status":"publish","type":"post","link":"https:\/\/www.nodesign.net\/blog\/le-design-logiciel\/","title":{"rendered":"Le Design Logiciel"},"content":{"rendered":"

Je publie, avec son autorisation, un texte \u00e9crit par Philippe Aigrain<\/strong> en 1985. Ce texte appelle \u00e0 la cr\u00e9ation d’un design logiciel et \u00e0 la prise en compte du grand public dans l’offre logiciel. A l’heure des assise du num\u00e9rique<\/a>, cet appel reste dramatiquement d’actualit\u00e9, quand on analyse notre difficult\u00e9 \u00e0 adresser le grand public dans les offres technologiques fran\u00e7aise de produit\/services de consommation. (Cet article fut publi\u00e9 \u00e0 l’origine dans la revue Axe Sud, n\u00b0 d’Avril-Mai-Juin 1985 )<\/span><\/p>\n


\nIl existe un nombre croissant de biens de consommation qui soit sont des programmes informatiques, soit incorporent des programmes informatiques. La fa\u00e7on dont ces programmes ont \u00e9t\u00e9 con\u00e7us et r\u00e9alis\u00e9s, devient un facteur essentiel du succ\u00e8s de ces produits aupr\u00e8s du public, et de l\u2019\u00e9valuation que l\u2019on peut faire de leur int\u00e9r\u00eat culturel. Du point de vue de l\u2019utilisateur d\u2019une machine informatique ou informatis\u00e9e, il devient de plus en plus difficile de distinguer ce qui rel\u00e8ve des programmes qui y sont implant\u00e9s. D\u2019une fa\u00e7on g\u00e9n\u00e9rale, l\u2019utilisateur ne voit la machine qu\u2019\u00e0 travers les programmes, elle ne devient directement visible que par ses pannes, ses insuffisances (lenteur) ou les malfa\u00e7ons de ses programmes. Plus r\u00e9cemment, on a vu appara\u00eetre des machines dont certains \u00e9l\u00e9ments mat\u00e9riels visibles (souris par exemple) ou invisibles (organisation physique de la m\u00e9moire) sont directement fond\u00e9s sur une recherche concernant l\u2019apparence externe que doit avoir leur utilisation sous contr\u00f4le de programmes. On peut dire que le logiciel s\u2019empare du mat\u00e9riel : la campagne de promotion de Macintosh d\u2019Apple est enti\u00e8rement fond\u00e9e sur ce qu\u2019on peut appeler son \u00ab design logiciel \u00bb. Une prise de conscience de l\u2019importance de ce type de facteurs se d\u00e9veloppe partout. Cependant, l\u2019abord qui pr\u00e9vaut actuellement en France, est remarquablement \u00e9triqu\u00e9, du fait des caract\u00e9ristiques de l\u2019industrie et de la recherche fran\u00e7aise en informatique. Cet article voudrait contribuer \u00e0 \u00e9largir le champ des r\u00e9flexions dans le domaine. L\u2019informatique s\u2019est longtemps d\u00e9velopp\u00e9e \u00e0 l\u2019\u00e9cart du grand public, dans les univers de l\u2019arm\u00e9e, de la gestion des entreprises, des laboratoires, et dans une moindre mesure, de la production industrielle. Il existe de plus une r\u00e9pugnance traditionnelle des gros industriels fran\u00e7ais \u00e0 la prise en compte des contraintes sp\u00e9cifiques de la conception de produits grand public sur des march\u00e9s non prot\u00e9g\u00e9s. L\u2019utilisateur grand public est souvent per\u00e7u comme un utilisateur professionnel en plus b\u00eate et moins familier avec la machine. De ce fait, on renforce simplement lorsqu\u2019on s\u2019adresse \u00e0 lui, une approche en termes de normes, de qualit\u00e9 et d\u2019efficacit\u00e9 (s\u00e9curit\u00e9, faible co\u00fbt, ergonomie, etc\u2026) de la production logicielle. C\u2019est cela que l\u2019on appelle le g\u00e9nie logiciel. Bien s\u00fbr, il existe de nombreuses \u00e9quipes ou entreprises que leurs int\u00e9r\u00eats, ou leur exposition \u00e0 la concurrence poussent \u00e0 effectuer des r\u00e9alisations tout \u00e0 fait int\u00e9ressantes du point de vue du design logiciel, mais ces d\u00e9marches ne trouvent pas de relais dans la recherche ou la formation, elles ne contribuent pratiquement pas \u00e0 la diffusion d\u2019un savoir-faire. Cette situation conduit \u00e0 poser deux questions : Pourquoi l\u2019approche normative en mati\u00e8re de logiciels a-t-elle autant de poids ? Sur quelles bases une approche en termes de design pourrait-elle se d\u00e9velopper ? Ces questions sont d\u2019autant plus importantes que contrairement \u00e0 un discours souvent entendu (\u00ab les jeunes doivent apprendre l\u2019informatique comme une seconde langue \u00bb) on est loin d\u2019avoir atteint une d\u00e9finition claire et unique des moyens et des m\u00e9thodes souhaitables en mati\u00e8re de logiciels. Au contraire, nous vivons l\u2019\u00e8re de l\u2019\u00e9clatement, de la multiplication des langages, des types d\u2019interaction avec l\u2019utilisateur. L\u2019approche normative, s\u00e9quelle de la pr\u00e9histoire du logiciel Pour comprendre le poids de l\u2019approche normative, qui cherche \u00e0 d\u00e9finir une bonne fa\u00e7on de faire du logiciel, un petit parcours historique est n\u00e9cessaire. En 1951, une dizaine de machines fonctionnaient dans le monde, \u00e0 qui on peut plus ou moins attribuer r\u00e9trospectivement le nom d\u2019ordinateurs (8 aux Etats-Unis, 2 en Grande-Bretagne). Ces machines \u00e9taient en g\u00e9n\u00e9ral d\u00e9di\u00e9es \u00e0 des activit\u00e9s particuli\u00e8res (calcul m\u00e9t\u00e9orologique, balistique, statistique, scientifique, etc.), m\u00eame si elles \u00e9taient capables d\u2019effectuer d\u2019autres types de calculs. Les moyens de communication de ces machines avec l\u2019ext\u00e9rieur \u00e9taient des plus r\u00e9duits, m\u00eame pour l\u2019introduction des programmes ; ils consistaient en des lecteurs de rubans perfor\u00e9s, de cartes perfor\u00e9es, des fiches que l\u2019on enfichaient dans des trous aux endroits appropri\u00e9s, et exceptionnellement (machines de Stiblitz aux Bell Laboratoires), un t\u00e9l\u00e9type reli\u00e9 \u00e0 l\u2019ordinateur. On \u00e9vitait soigneusement toute forme d\u2019interaction pendant le d\u00e9roulement d\u2019un programme, qui, dans l\u2019\u00e9tat de la technique d\u2019alors, aurait consid\u00e9rablement ralenti et perturb\u00e9 le fonctionnement de la machine. La question d\u2019alors n\u2019\u00e9tait donc pas le dialogue homme-machine, mais seulement la commande de la machine par un programme. John Backus, inventeur du FORTRAN et promoteur actuel de la programmation fonctionnelle, a racont\u00e9 dans un article \u00e0 quoi cela ressemblait de programmer dans les ann\u00e9es 50. Cela tenait plus de l\u2019exercice de survie dans un milieu hostile et impr\u00e9visible, que de l\u2019application de r\u00e8gles de travail \u00e9prouv\u00e9es. La programmation a commenc\u00e9 comme un art, \u00ab Une astuce pour chaque probl\u00e8me \u00bb, \u00e9tait sa devise. Chaque programme \u00e9tait une pi\u00e8ce unique, et l\u2019on repartait souvent de z\u00e9ro pour faire le suivant. Une majorit\u00e9 des artistes programmeurs se recrutaient chez les femmes, au d\u00e9part du fait de leur plus grande disponibilit\u00e9 pendant la guerre, mais la tendance s\u2019est maintenue dans l\u2019apr\u00e8s- guerre. Programmer consistait alors \u00e0 aligner des \u00ab instructions \u00bb dans ce qu\u2019on appelait \u00e0 l\u2019\u00e9poque du \u00ab code-machine \u00bb, suites de 0 et de 1 particuli\u00e8rement peu expressives du point de vue humain, mais que la machine est capable de comprendre et d\u2019ex\u00e9cuter. Depuis, les machines n\u2019ont d\u2019ailleurs pas \u00e9volu\u00e9 de ce point de vue, mais les outils que l\u2019on s\u2019est donn\u00e9 pour leur parler font la diff\u00e9rence. Passer d\u2019un probl\u00e8me (\u00ab calculer les tables de tir pour tel type d\u2019obus \u00bb pour prendre un exemple d\u2019\u00e9poque) \u00e0 un programme, \u00e9tait un processus long et r\u00e9barbatif. Mais la vraie difficult\u00e9 commen\u00e7ait quand on essayait de faire \u00ab tourner \u00bb le programme. Il n\u2019existait aucune aide pour trouver les raisons du non-fonctionnement d\u2019un programme. Il fallait se livrer \u00e0 ce qu\u2019un sp\u00e9cialiste appela \u00ab la lecture dans les entrailles \u00bb, c\u2019est-\u00e0-dire fouiller dans la visualisation de tout le contenu de la m\u00e9moire, gigantesque collection de 0 et de 1, juste avant que l\u2019incident ne se produise. En l\u2019absence de possibilit\u00e9 ou de r\u00e9ussite de la lecture dans les entrailles, il restait \u00e0 modifier le programme jusqu\u2019\u00e0 ce que quelque bien s\u2019en suive. Les premiers programmeurs b\u00e9n\u00e9ficiaient du d\u00e9licieux pouvoir qui s\u2019attache \u00e0 ceux qui poss\u00e8dent une sp\u00e9cialit\u00e9 rare et myst\u00e9rieuse. La plupart d\u2019entre eux n\u2019\u00e9taient que des utilisateurs form\u00e9s sur le tas par la dure n\u00e9cessit\u00e9. Loin de publier les \u00ab trucs \u00bb qu\u2019ils inventaient dans la presse technique, ils les gardaient secrets. Cette situation \u00e9tait bien s\u00fbr tout \u00e0 fait incompatible avec une large diffusion des ordinateurs chez ces clients m\u00e9fiants que sont les grandes entreprises et les administrations. Un important effort de recherche et de d\u00e9veloppement fut donc entrepris, principalement sur l\u2019initiative des constructeurs, IBM en t\u00eate, pour que la programmation cesse d\u2019\u00eatre un art, pour devenir une technique, et qui sait une \u00ab industrie \u00bb. Les tenants actuels du \u00ab g\u00e9nie logiciel \u00bb ont une fa\u00e7on \u00e0 eux de raconter l\u2019histoire des 30 ann\u00e9es qui suivent : ils y voient un progr\u00e8s constant vers la d\u00e9finition d\u2019outils toujours plus s\u00fbrs et performants, toujours plus int\u00e9gr\u00e9s les uns avec les autres, pour culminer aujourd\u2019hui dans la cr\u00e9ation des ateliers int\u00e9gr\u00e9s de production logicielle. Ainsi on aurait invent\u00e9 des langages de programmation de mieux en mieux d\u00e9finis, du couple FORTRAN COBOL, en passant par ALGOL et PASCAL, jusqu\u2019\u00e0 ADA, le dernier choisi par l\u2019arm\u00e9e am\u00e9ricaine. Dans le m\u00eame temps, les environnements de d\u00e9veloppement (c\u2019est-\u00e0-dire tout ce qu\u2019il y a autour d\u2019un langage pour aider \u00e0 s\u2019en servir, du syst\u00e8me d\u2019op\u00e9rations de la machine aux \u00e9diteurs en passant par les \u00ab d\u00e9buggers \u00bb) auraient suivi la m\u00eame courbe ascendante de progr\u00e8s, et permettraient de traiter aujourd\u2019hui jusqu\u2019\u00e0 la sp\u00e9cification des probl\u00e8mes \u00e0 traiter par l\u2019informatique et m\u00eame la mesure de la qualit\u00e9 des logiciels. Dans le m\u00eame ordre d\u2019id\u00e9es, la communication homme- machine fait \u00e9galement l\u2019objet d\u2019une approche normative, visant \u00e0 d\u00e9gager les principes syst\u00e9matiques de pr\u00e9sentation de l\u2019information \u00e0 l\u2019utilisateur, les moyens par lesquels il convient de solliciter ses actions, etc\u2026 Cette fa\u00e7on de raconter l\u2019histoire et d\u2019organiser le pr\u00e9sent du logiciel est inexacte et dangereuse. Elle consisterait, si elle \u00e9tait adopt\u00e9e partout, \u00e0 g\u00e9n\u00e9raliser des principes d\u2019organisation issus de l\u2019univers militaire ou des tr\u00e8s gros industriels de l\u2019a\u00e9ronautique, de l\u2019\u00e9nergie et de l\u2019espace. Ces organisations r\u00e9alisent des d\u00e9veloppements logiciels gigantesques, dans lesquels des centaines de programmeurs diff\u00e9rents sont impliqu\u00e9s, qui vont aboutir \u00e0 des programmes dont la dur\u00e9e de vie est souvent de 15 ou 20 ans, et qui ne sont pas vendus sur un march\u00e9 d\u2019utilisateurs (ceux qui d\u00e9cident de les acheter ne sont pas ceux qui vont les utiliser). Dans de telles conditions, il n\u2019est pas surprenant qu\u2019une approche normative, cherchant \u00e0 trouver le bon langage, la bonne communication homme-machine, se soit impos\u00e9e. Mais si l\u2019on consid\u00e8re l\u2019ensemble des domaines d\u2019application de l\u2019informatique, le paysage devient tout autre. Le cas des langages de programmation est parlant : il en existe des dizaines aujourd\u2019hui, et un des gros probl\u00e8mes de la communaut\u00e9 scientifique consiste \u00e0 emp\u00eacher chaque chercheur qui a une id\u00e9e, d\u2019inventer imm\u00e9diatement un langage de programmation pour la mettre en \u0153uvre. Chacun de ces langages se r\u00e9v\u00e8le \u00eatre bon \u2026 \u00e0 quelque chose, c\u2019est-\u00e0-dire \u00e0 un certain type d\u2019utilisateur et d\u2019utilisation. Cela ne signifie nullement qu\u2019il est impossible de faire des choix, de critiquer tel ou tel langage, mais que les crit\u00e8res \u00e0 mettre en \u0153uvre sont multiples et contradictoires. Parmi les langages les plus utilis\u00e9s, certains comme Basic, APL ou LISP sont absents de la fameuse trajectoire du progr\u00e8s suppos\u00e9, mais ont leurs adeptes farouches. Mais le cas de la communication homme-machine est plus important encore, car il concerne l\u2019ensemble des utilisateurs de l\u2019informatique ou des objets techniques informatis\u00e9s, il touche l\u2019\u00abapparence \u00bb externe des logiciels et non le seul programmeur. L\u00e0 encore, il ne saurait \u00eatre question de n\u00e9gliger l\u2019accumulation d\u2019outils et de savoir-faire des 30 derni\u00e8res ann\u00e9es, mais de mesurer qu\u2019il s\u2019agit d\u2019un d\u00e9veloppement polymorphe et que les choix \u00e0 effectuer dans la conception d\u2019un produit qui se veut aujourd\u2019hui culturel ne sont pas de l\u2019ordre de l\u2019application de normes de qualit\u00e9 ou d\u2019efficacit\u00e9, mais bien de choix culturels. Pour donner un exemple du type de choix \u00e0 effectuer dans la cr\u00e9ation d\u2019un logiciel, choix dont la composition constitue le design logiciel, la suite de l\u2019article explore une s\u00e9rie d\u2019oppositions qui partagent diff\u00e9rents types de logiciels, et plus g\u00e9n\u00e9ralement d\u2019objets techniques. La Bo\u00eete Noire et la Maison de Verre Un premier type d\u2019oppositions prend forme autour de la question : \u00ab\u00a0un programme doit-il rendre visible le processus et les \u00e9tapes interm\u00e9diaires par lesquels il passe de ses donn\u00e9es \u00e0 ses r\u00e9sultats ?\u00a0\u00bb. Dans le mod\u00e8le de la \u00ab bo\u00eete noire \u00bb, l\u2019utilisateur ne doit rien voir entre ses actions et leurs r\u00e9sultats recherch\u00e9s : on parle d\u2019utilisation transparente de l\u2019objet technique, parce que l\u2019on ne voit pas l\u2019objet technique lui-m\u00eame, mais seulement ce qu\u2019il y a \u00ab derri\u00e8re \u00bb, le but pour lequel on l\u2019utilise. Dans le mod\u00e8le de la \u00ab maison de verre \u00bb, le programme rend au contraire visible le processus qu’il effectue pour passer de donn\u00e9es \u00e0 des r\u00e9sultats. Cette visualisation se fait en g\u00e9n\u00e9ral en montrant des \u00e9tapes interm\u00e9diaires, ou bien en visualisant un certain nombre de variables d\u2019\u00e9tat. Le mod\u00e8le de la bo\u00eete noire correspond en g\u00e9n\u00e9ral \u00e0 une recherche d\u2019\u00e9conomie des actions de l\u2019utilisateur, alors que celui de la maison de verre correspond \u00e0 une recherche de contr\u00f4le fin, ou \u00e0 un m\u00e9canisme d\u2019\u00e9laboration progressive d\u2019une strat\u00e9gie. Un exemple non-informatique est celui de l\u2019automobile : entre la bo\u00eete de vitesses automatique, et la bo\u00eete de vitesses classique agr\u00e9ment\u00e9e d\u2019un compte-tours, on peut choisir diff\u00e9rents degr\u00e9s de mise en \u00e9vidence pour le conducteur du processus m\u00e9canique. Les sp\u00e9cialistes de la diffusion de l\u2019informatique ont souvent tendance \u00e0 consid\u00e9rer que seul le mod\u00e8le de la \u00ab bo\u00eete noire \u00bb est compatible avec des utilisations grand public. Ils basent cette opinion sur le fait que la plupart des objets techniques qui se sont largement diffus\u00e9s (t\u00e9l\u00e9phone, t\u00e9l\u00e9vision, par exemple) sont du type Bo\u00eete Noire. Avoir \u00e0 se confronter au processus technique, fut-ce \u00e0 travers une visualisation tout \u00e0 fait d\u00e9tourn\u00e9e, est vu comme une nuisance acceptable par les seuls sp\u00e9cialistes. Outre que l\u2019exemple d\u00e9j\u00e0 cit\u00e9 de l\u2019automobile devrait relativiser cette affirmation, le cas des programmes informatiques est tout \u00e0 fait sp\u00e9cial. Un programme informatique sert \u00e0 manipuler des symboles, et \u00e0 manipuler des objets par le biais de cette manipulation des symboles. De ce fait, il est possible que les \u00e9tats interm\u00e9diaires d\u2019un programme soient \u00ab de m\u00eame nature \u00bb que ses r\u00e9sultats. Ainsi, il est possible de s\u2019y confronter sans avoir \u00e0 entrer dans les d\u00e9tails de la quincaillerie technique. De plus, il est fr\u00e9quent que ce que l\u2019on cherche, et le chemin \u00e0 parcourir pour y parvenir, ne se d\u00e9finissent que progressivement au cours de l\u2019utilisation. La personne qui interroge une banque de donn\u00e9es pour y d\u00e9couvrir la maison de vacances o\u00f9 passer une semaine est peu susceptible de dire \u00e0 priori que celle-ci r\u00e9pond \u00e0 tel ou tel crit\u00e8re. Il est bien plus probable que confront\u00e9e \u00e0 l\u2019 \u00ab image \u00bb d\u2019une maison (r\u00e9elle ou fictive), elle puisse \u00e9noncer ce qui lui y pla\u00eet et lui y d\u00e9pla\u00eet et se promener ainsi de maison en maison, jusqu\u2019\u00e0 \u00ab arr\u00eater \u00bb son choix. La Maison de Verre repr\u00e9sente donc un mod\u00e8le aussi valide que la bo\u00eete noire pour certains programmes. Mais qui plus est, le choix entre les deux mod\u00e8les n\u2019est pas d\u2019ordre fonctionnel. Il ne suffit pas d\u2019examiner le \u00ab probl\u00e8me \u00bb et de d\u00e9terminer si ses caract\u00e9ristiques rel\u00e8vent de l\u2019une ou l\u2019autre approche, une certaine part de choix \u00ab stylistique \u00bb est n\u00e9cessaire. C\u2019est ce qui justifie une approche en termes de design, et non un simple approfondissement de l\u2019approche normative. Question de rythme Pendant longtemps, la question du rythme d\u2019un programme interactif s\u2019est pos\u00e9e dans des termes tr\u00e8s simples : ces sacr\u00e9es machines r\u00e9pondaient toujours trop lentement ! On a d\u00e9velopp\u00e9 un certain nombre de r\u00e8gles en mati\u00e8re de r\u00e9actions d\u2019un programme aux actions de l\u2019utilisateur : notifier imm\u00e9diatement que l\u2019action de l\u2019utilisateur a bien \u00e9t\u00e9 enregistr\u00e9e, rendre ses effets les plus rapides possibles, et si le traitement ne peut \u00eatre bref, signaler d\u2019une fa\u00e7on ou d\u2019une autre qu\u2019il est en train de se d\u00e9rouler de fa\u00e7on \u00e0 ce que l\u2019utilisateur sache qu\u2019on s\u2019occupe de lui \u2026 Mais la question du rythme se pose aussi d\u2019une toute autre mani\u00e8re : \u00e0 quel rythme demande-t-on \u00e0 l\u2019utilisateur d\u2019agir ? tous les combien de temps sollicite-t-on ses actions ? Combien de temps est-ce qu\u2019on lui laisse pour les effectuer ? Les jeux vid\u00e9os donnent un exemple de rythme d\u2019interaction o\u00f9 l\u2019on recherche le tempo le plus \u00e9lev\u00e9 possible, et o\u00f9 ce tempo est enti\u00e8rement fix\u00e9 par le programme. Le programme effectue une boucle serr\u00e9e \u00ab saisie des actions de l\u2019utilisateur sur les boutons et leviers de commande \/ r\u00e9percussion sur l\u2019\u00e9tat de l\u2019univers du jeu \u00bb, et si l\u2019utilisateur ne fait rien, cela \u00e9quivaut \u00e0 des actions par d\u00e9faut, qui le plus souvent le conduisent \u00e0 une perte certaine. Ce type de rythme a l\u2019avantage de capter enti\u00e8rement l\u2019attention de l\u2019utilisateur, mais cet avantage peut se r\u00e9v\u00e9ler \u00eatre un s\u00e9rieux inconv\u00e9nient dans d\u2019autres contextes. Il est parfois utile et agr\u00e9able de disposer d\u2019autant de temps que l\u2019on le veut pour prendre une d\u00e9cision d\u2019action, ou de pouvoir interagir avec un programme en faisant autre chose en m\u00eame temps, ou de pouvoir interagir avec plusieurs programmes simultan\u00e9ment. Le tempo d\u2019interaction est un d\u00e9terminant essentiel du type de pens\u00e9e qui sera favoris\u00e9 par un programme. L\u2019exemple de la diff\u00e9rence entre les parties d\u2019\u00e9checs dites de Blitz (\u00e9clair) et les parties normales en est une illustration. Enfin, laisser un temps de r\u00e9flexion assez long \u00e0 l\u2019utilisateur suppose qu\u2019on lui pr\u00e9sente une information riche, faute de quoi la lassitude est in\u00e9vitable. Simulation et reconstruction Un tr\u00e8s grand nombre de programmes informatiques remplissent des fonctions qui ont \u00e9t\u00e9 ou sont encore remplies par des personnes, ou au moyen d\u2019objets techniques non-informatis\u00e9s. Le fait que l\u2019informatique manipule des symboles, permet d\u2019envisager des rapports de type tr\u00e8s diff\u00e9rents entre le programme et les r\u00e9f\u00e9rents ext\u00e9rieurs que sont par exemple, le dialogue parl\u00e9 et \u00e9crit avec un employ\u00e9 de banque pour le programme d\u2019un distributeur automatique de billets, ou l\u2019\u00e9criture au moyen d\u2019un style sur une feuille de papier pour un programme de traitement de textes (dans ce cas, l\u2019usage d\u2019une machine \u00e0 \u00e9crire constitue bien s\u00fbr un autre r\u00e9f\u00e9rent possible). Le programme peut entretenir deux types de rapports au moins avec ces r\u00e9f\u00e9rents ext\u00e9rieurs : il peut chercher \u00e0 les \u00ab simuler \u00bb, c\u2019est-\u00e0-dire \u00e0 les reproduire plus ou moins sur un support diff\u00e9rent. Cette simulation peut s\u2019exercer \u00e0 plusieurs niveaux : on peut simplement installer un certain parall\u00e9lisme d\u2019op\u00e9rations, ou aller jusqu\u2019\u00e0 copier dans le d\u00e9tail, le type de gestes qui \u00e9tait effectu\u00e9 dans la situation ext\u00e9rieure, comme cela se fait dans certaines palettes graphiques qui essayent de simuler la gestuelle du peintre. Mais on peut aussi chercher \u00e0 reconstruire compl\u00e8tement l\u2019activit\u00e9 que r\u00e9alise le programme informatique, proposer d\u2019arriver \u00e0 des buts plus ou moins semblables par des moyens compl\u00e8tement distincts. Par exemple, certains programmes de composition musicale prennent avantage de la possibilit\u00e9 de d\u00e9finir dans l\u2019informatique des traitements syst\u00e9matiques et complexes de symboles pour introduire des techniques de composition nouvelle (d\u2019autres simulent l\u2019\u00e9criture musicale usuelle). En robotique aussi, les deux mod\u00e8les sont pr\u00e9sents, avec les robots peintres qui copient les gestes d\u2019un manipulateur c\u00f4t\u00e9 simulation, et de nombreux robots \u00e0 commande num\u00e9rique c\u00f4t\u00e9 reconstruction. Dans un premier temps, la plupart des programmes informatiques ont fonctionn\u00e9 sous la forme \u00ab reconstruction \u00bb\u2026 parce que l\u2019on ne pouvait pas faire autrement, les moyens techniques ne permettant pas la simulation r\u00e9ussie de situations souvent complexes \u00e0 repr\u00e9senter. Dans un second temps, des programmes sont apparus, comme le syst\u00e8me STAR de Xerox, sur lequel a \u00e9t\u00e9 copi\u00e9 le syst\u00e8me d\u2019op\u00e9rations du Macintosh, qui sont enti\u00e8rement fond\u00e9s sur la simulation. Dans le cas de STAR et Macintosh, on simule sur la machine le fonctionnement d\u2019un bureau physique, avec ses dossiers, sa poubelle, son horloge, etc\u2026 L\u2019approche \u00ab simulation \u00bb a conduit \u00e0 des succ\u00e8s certains, et facilite l\u2019apprentissage en pla\u00e7ant l\u2019utilisateur dans une situation \u00ab reconnaissable \u00bb. On aurait cependant tort de croire qu\u2019elle est une panac\u00e9e : la libert\u00e9, le caract\u00e8re exploratoire de l\u2019approche \u00ab reconstruction \u00bb a \u00e9galement des avantages. Langage naturel et langage formel Les deux oppositions abord\u00e9es maintenant ont un rapport \u00e9troit avec la pr\u00e9c\u00e9dente, sans pour autant se confondre avec elle. Un important effort de recherche est actuellement entrepris pour la compr\u00e9hension du langage naturel par les machines. Cet effort bute sur de grosses difficult\u00e9s, et pose des probl\u00e8mes philosophiques et \u00e9pist\u00e9mologiques de taille. Certains chercheurs limitent leurs efforts \u00e0 la compr\u00e9hension du langage d\u00e9j\u00e0 cod\u00e9 sous formes de symboles (entr\u00e9e au clavier de phrases), d\u2019autres cherchent \u00e0 reconna\u00eetre directement le langage parl\u00e9 ou \u00e9crit. Comme ces chercheurs contribuent de fa\u00e7on passionnante \u00e0 une meilleure connaissance du langage humain, et que leur enjeu para\u00eet si essentiel, une sorte de doxa s\u2019est cr\u00e9\u00e9e et plus personne ne semble douter que cela serait un avantage de pouvoir dialoguer avec les machines en langage naturel. Il y a l\u00e0 un cas particulier de la vogue de la simulation, c\u2019est-\u00e0-dire que l\u2019on valorise le fait que le rapport homme ou femme\/machine soit une simulation du rapport entre deux \u00eatres humains. La plupart des programmes de bases de donn\u00e9es vantent aujourd\u2019hui en mentant plus ou moins leurs interfaces \u00ab proches du langage naturel \u00bb. Or, il n\u2019est pas du tout certain que lorsqu\u2019on doit donner des ordres d\u2019action \u00e0 une machine informatis\u00e9e, ce soit syst\u00e9matiquement un avantage de le faire en langage naturel, plut\u00f4t que dans un langage formel. On verra plus loin que dans certains cas, on peut tr\u00e8s bien se passer compl\u00e8tement de langage de commandes, mais supposons ici qu\u2019il en faille un. Un langage de commandes sert \u00e0 indiquer \u00e0 une machine ce qu\u2019elle doit faire. Il s\u2019agit souvent d\u2019une succession assez complexe d\u2019actions tr\u00e8s simples. La qualit\u00e9 d\u2019un langage de commandes est alors un compromis entre la facilit\u00e9 de l\u2019utilisateur \u00e0 s\u2019exprimer dans ce langage, la concision des ordres quand on les \u00e9nonce dans ce langage (faire un long discours \u00e0 une machine peut \u00eatre tr\u00e8s ennuyeux), et la non-ambiguit\u00e9 des ordres \u00e9nonc\u00e9s, etc\u2026 On peut bien s\u00fbr imaginer une solution mi-ch\u00e8vre \u2013 mi-chou, consistant \u00e0 permettre l\u2019entr\u00e9e des commandes en langage naturel (en supposant r\u00e9solu convenablement le probl\u00e8me de sa compr\u00e9hension, ce qui est plus que douteux pour les prochaines ann\u00e9es) ou en langage formel, suivant les pr\u00e9f\u00e9rences ou le savoir-faire de l\u2019utilisateur. On peut aussi aborder ce choix comme un choix \u00ab stylistique \u00bb. Ressemblance et codage L\u2019opposition entre ressemblance et codage concerne les programmes qui sont amen\u00e9s \u00e0 pr\u00e9senter \u00e0 l\u2019utilisateur des repr\u00e9sentations d\u2019objets appartenant \u00e0 un univers de r\u00e9f\u00e9rence, en g\u00e9n\u00e9ral parce qu\u2019ils se situent dans l\u2019approche \u00ab simulation \u00bb. La repr\u00e9sentation de ces objets peut \u00eatre plus ou moins \u00ab ressemblante \u00bb. Par exemple, pour repr\u00e9senter un dossier contenant des informations, on pourra utiliser une photographie de dossier (transf\u00e9r\u00e9e sur un \u00e9cran vid\u00e9o) ou, au contraire, un pictogramme tr\u00e8s simple, une repr\u00e9sentation cod\u00e9e symbolisant un dossier. La ressemblance a l\u2019avantage d\u2019induire une illusion de r\u00e9alit\u00e9 plus forte, et le codage de permettre des manipulations plus ais\u00e9es. On trouve un bon \u00e9ventail de choix dans le domaine des jeux vid\u00e9os, entre un jeu comme Pacman, et les jeux dits \u00e0 image r\u00e9elle bas\u00e9s sur des vid\u00e9odisques. Encore une fois, on aurait tort de consid\u00e9rer qu\u2019il y a progr\u00e8s \u00e9vident dans le passage \u00e0 l\u2019image \u00ab r\u00e9elle \u00bb, simplement parce que celle-ci s\u2019est trouv\u00e9e \u00eatre possible technologiquement quelques ann\u00e9es plus tard. Le syst\u00e8me du Macintosh ne gagnerait \u00e9videmment rien \u00e0 utiliser des repr\u00e9sentations ressemblantes \u00e0 la place de ses \u00ab icones \u00bb. Dans les syst\u00e8mes de parcours d\u2019ensembles d\u2019images bas\u00e9s sur la m\u00e9taphore du voyage, l\u2019utilisation, au moment des choix propos\u00e9s \u00e0 l\u2019utilisateur, d\u2019images du m\u00eame type que celles parcourues, conduit au choix inverse. Commande gestuelle et langage de commande Un nombre important de programmes informatiques sollicitent les actions de leurs utilisateurs non sous la forme de commandes exprim\u00e9es dans un langage, mais sous la forme de gestes. La commande gestuelle a l\u2019avantage de l\u2019imm\u00e9diatet\u00e9, et de la continuit\u00e9 avec les habitudes de commande des objets techniques non-informatis\u00e9s. La commande par un langage permet la formulation de commandes complexes, et r\u00e9utilisables. On \u00e9vitera le faux d\u00e9bat qui r\u00e9sulte du fait que pour exprimer des ordres \u00e0 une machine dans un langage, on utilise en g\u00e9n\u00e9ral des gestes (par exemple, frapper les touches d\u2019un clavier) et qu\u2019\u00e0 l\u2019inverse on peut parler de langage gestuel. Dans de nombreux cas, on peut choisir entre langage de commande et commande gestuelle en analysant ce sur quoi portent les actions de la machine. On privil\u00e9giera le langage de commande quand il s\u2019agit d\u2019effectuer des manipulations complexes de signes \u00e9l\u00e9mentaires, et la commande gestuelle quand il s\u2019agit d\u2019effectuer des manipulations simples d\u2019objets complexes. Mais cette d\u00e9termination normative se r\u00e9v\u00e9lera souvent insuffisante dans des cas \u00ab interm\u00e9diaires \u00bb. Il ne fait pas de doute que ce choix est aussi affaire de go\u00fbt et d\u2019esth\u00e9tique : \u00ab \u00eatre aux commandes \u00bb et \u00ab donner des ordres \u00bb sont deux situations dont les connotations sont fort diff\u00e9rentes. Pr\u00e9visibilit\u00e9 et surprise Jusqu\u2019\u00e0 ces derniers temps, lorsqu\u2019une machine nous faisait une surprise, c\u2019\u00e9tait une mauvaise surprise. On a ainsi pris l\u2019habitude de consid\u00e9rer qu\u2019il \u00e9tait toujours souhaitable de pouvoir pr\u00e9voir quelle serait la r\u00e9action d\u2019un programme \u00e0 une action de son utilisateur. Les premiers contre-exemples \u00e0 cette r\u00e8gle sont venus du domaine des jeux : dans un jeu comme Adventure, par exemple, une grande partie du plaisir de jouer vient de l\u2019impr\u00e9visibilit\u00e9 de r\u00e9actions du programme aux ordres qui lui sont donn\u00e9s. On pouvait encore croire, vu la sp\u00e9cificit\u00e9 du domaine des jeux, \u00e0 une exception confirmant la r\u00e8gle. Puis on a vu surgir des r\u00e9flexions sur la notion de programme ind\u00e9terministe dans l\u2019informatique th\u00e9orique, ou des applications audiovisuelles interactives qui r\u00e9servent bien des surprises (pas forc\u00e9ment mauvaises) \u00e0 leurs utilisateurs. D’une fa\u00e7on plus g\u00e9n\u00e9rale, dans toutes les applications o\u00f9 l’utilisateur n’est pas sens\u00e9 savoir ce qu\u2019il veut, ou s\u2019il le sait, n\u2019est pas sens\u00e9 avoir trop d\u2019id\u00e9es sur les moyens d\u2019y parvenir, la surprise peut \u00eatre un ressort utile et agr\u00e9able. Le design graphique informatique La conception graphique des \u00e9crans ou des sorties imprim\u00e9es des programmes informatiques met bien s\u00fbr en \u0153uvre des techniques voisines de celles du design graphique en g\u00e9n\u00e9ral. Mais une petite histoire vraie, cont\u00e9e ci-apr\u00e8s fera percevoir \u00e0 quel point la perception globale qu\u2019apporte le design logiciel est n\u00e9cessaire dans ce domaine \u00e9galement. Lors de l\u2019apparition du Minitel, les protestations fus\u00e8rent de toutes parts contre les limitations techniques de cet appareil qui ne permettait que l\u2019utilisation des graphismes rudimentaires du fait de la technique alpha-mosa\u00efque qui y est employ\u00e9e. En r\u00e9action \u00e0 ces critiques, l\u2019Office d\u2019Annonces (une filiale du groupe Havas) et \u00e9galement quelques soci\u00e9t\u00e9s de services, embauch\u00e8rent pour le vid\u00e9otexte (dont le Minitel est l\u2019une des formes) des graphistes professionnels. Un travail important fut entrepris, et effectivement, aboutit \u00e0 la r\u00e9alisation d\u2019\u00e9crans graphiques qui tiraient part des limitations m\u00eame de l\u2019appareil pour obtenir des effets originaux et, ma foi, r\u00e9ussis. Ces \u00e9crans furent abondamment photographi\u00e9s, reproduits dans la presse, pr\u00e9sent\u00e9s \u00e0 des chefs d\u2019Etats et lou\u00e9s \u00e0 tout point de vue. Puis, on essaya d\u2019introduire dans des applications t\u00e9l\u00e9matiques ces \u00e9crans au graphisme \u00e9labor\u00e9. Lors de leur premi\u00e8re utilisation, les usagers de l\u2019application t\u00e9l\u00e9matique \u00e9taient ravis de l\u2019esth\u00e9tique des \u00e9crans, mais lors d\u2019utilisations r\u00e9guli\u00e8res, ils finissaient par les prendre en horreur. En effet, plus le graphisme d\u2019un \u00e9cran est \u00e9labor\u00e9, plus son dessin sur l\u2019\u00e9cran est lent du fait de la lenteur de la transmission t\u00e9l\u00e9phonique. Or, la structure des applications t\u00e9l\u00e9matiques imposait le passage r\u00e9p\u00e9t\u00e9 par les m\u00eames \u00e9crans. A l\u2019heure actuelle, les peintres et les graphistes en question utilisent le savoir-faire acquis lors de cette exp\u00e9rience en travaillant sur des outils beaucoup plus performants (type palette Graph-8) et fabriquent des images \u00e0 destination des supports imprim\u00e9s ou vid\u00e9o. Quant aux applications t\u00e9l\u00e9matiques, elles se contentent de quelques \u00ab logos \u00bb sophistiqu\u00e9s, et d\u2019un graphisme minimal. Plus g\u00e9n\u00e9ralement, la conception graphique n\u2019est pas un domaine ind\u00e9pendant du reste du design logiciel. Elle n\u2019est pas le petit domaine r\u00e9serv\u00e9 o\u00f9 les points de vue artistique ou culturel auraient droit de cit\u00e9, tout le reste de la conception des programmes relevant d\u2019une approche purement technicienne. Vers le design logiciel Il y a donc une place pour le design logiciel, il y a des questions qui se posent \u00e0 lui, des choix \u00e0 faire, des styles \u00e0 cr\u00e9er, des gens \u00e0 s\u00e9duire. Mais au fait, o\u00f9 rencontre-t-on cette b\u00eate ? Et bien, on ne la rencontre pas. Le design logiciel n\u2019est qu\u2019une id\u00e9e, mais cela n\u2019interdit pas de dessiner les contours qu\u2019il pourrait prendre si, par aventure, on d\u00e9cidait de faire de cette id\u00e9e un projet. La pire des fa\u00e7ons d\u2019y parvenir serait de croire qu\u2019il s\u2019agit d\u2019un m\u00e9tier, et \u00e0 la fa\u00e7on bien fran\u00e7aise, de cr\u00e9er une \u00e9cole pour y former de futurs designers logiciels, avant m\u00eame que l\u2019on sache quels sont les savoirs et les techniques effectivement mobilis\u00e9s dans cette activit\u00e9. Une phase d\u2019exp\u00e9rimentation est in\u00e9vitable, dans laquelle l\u2019essentiel est de mettre en contact des gens de sp\u00e9cialit\u00e9s diverses, et d\u2019int\u00e9r\u00eats suffisamment \u00e9clectiques, avec la r\u00e9alit\u00e9 de projets de cr\u00e9ation de programmes informatiques. Il ne faut pas se cacher que la difficult\u00e9 essentielle consiste \u00e0 trouver des cr\u00e9ateurs qui voient dans ce domaine un v\u00e9ritable enjeu de cr\u00e9ation. Ce ne pourra \u00eatre le cas que si une libert\u00e9 suffisante est laiss\u00e9e, dans un contexte exp\u00e9rimental, pour la d\u00e9finition d\u2019objets, de concepts informatiques originaux. N\u2019oublions pas que le syst\u00e8me STAR de Rank Xerox, dont le Macintosh n\u2019est qu\u2019un sous-produit, est le r\u00e9sultat d\u2019ann\u00e9es de travail d\u2019une \u00e9quipe pluridisciplinaire, et que ce syst\u00e8me fut un relatif \u00e9chec commercial, qui a surtout profit\u00e9 \u2026 \u00e0 ses concurrents. Dans ce domaine, comme dans tant d\u2019autres qui m\u00ealent technique et culture, il faut avoir le courage de ne pas se faire trop d\u2019illusions sur les retomb\u00e9es \u00e9conomiques \u00e0 court terme de cet effort de recherche. Il y a cependant des b\u00e9n\u00e9fices plus imm\u00e9diats que la collectivit\u00e9 peut attendre de l\u2019exp\u00e9rimentation dans ce domaine. Le principal est celui de la formation d\u2019un esprit critique, d\u2019un espace de discussion o\u00f9 ce genre de probl\u00e9matique ait droit de cit\u00e9. L\u2019essentiel des projets importants en mati\u00e8re d\u2019informatisation est mis en \u0153uvre en France par des administrations publiques ou financ\u00e9 par elles. Ces administrations, loin d\u2019exercer un pouvoir omnipr\u00e9sent et tentaculaire, sont soumises \u00e0 un r\u00e9seau de pressions \u00e9conomiques et institutionnelles qui ont le don d\u2019orienter leurs projets vers des choix plus que critiquables du point de vue culturel. La rubrique scientifique d\u2019Axe Sud contribuera prochainement \u00e0 la formation de cet esprit critique \u00e0 propos des r\u00e9seaux c\u00e2bl\u00e9s et de l\u2019exp\u00e9rience de Biarritz, de l\u2019informatisation des \u00e9coles et d\u2019autres sujets. Enfin, il faut lever une ambigu\u00eft\u00e9 que le ton pol\u00e9mique de cet article \u00e0 propos du g\u00e9nie logiciel a pu faire surgir. Le design logiciel ne se d\u00e9veloppera certainement pas en ignorant le savoir- faire technique de l\u2019informatique moderne, pas plus qu\u2019un designer de mobilier ne peut ignorer les techniques de production contemporaines. Il s\u2019agit au contraire d\u2019injecter dans l\u2019univers technique des exigences nouvelles. <\/p>\n

Philippe AIGRAIN <\/p>\n

Design logiciel <\/a>, Philippe Aigrain (avril 1985)<\/p>\n","protected":false},"excerpt":{"rendered":"

Je publie, avec son autorisation, un texte \u00e9crit par Philippe Aigrain<\/strong> en 1985. Ce texte appelle \u00e0 la cr\u00e9ation d’un design logiciel et \u00e0 la prise en compte du grand public dans l’offre logiciel. A l’heure des assise du num\u00e9rique<\/a>, cet appel reste dramatiquement d’actualit\u00e9, quand on analyse notre difficult\u00e9 \u00e0 adresser le grand public dans les offres technologiques fran\u00e7aise de produit\/services de consommation. (Cet article fut publi\u00e9 \u00e0 l’origine dans la revue Axe Sud, n\u00b0 d’Avril-Mai-Juin 1985 )<\/span><\/p>\n","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[9],"tags":[76,87,43,29,97,22,30,59,95,57,72,108,31,53,45,54,60,33,34,55,25,79,90,92,26,73,35,36,44,27,38,56,48],"class_list":["post-1836","post","type-post","status-publish","format-standard","hentry","category-design-innovation","tag-appareil","tag-automobile","tag-conception","tag-design","tag-espace","tag-exposition","tag-formation","tag-france","tag-graphisme","tag-gui","tag-idees","tag-illustration","tag-information","tag-informatique","tag-interface","tag-interfaces","tag-lab","tag-objet","tag-objets","tag-outils","tag-photo","tag-qualite","tag-robot","tag-robotique","tag-science","tag-scientifique","tag-service","tag-services","tag-technique","tag-ui","tag-ux","tag-velo","tag-vision"],"_links":{"self":[{"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/posts\/1836","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/comments?post=1836"}],"version-history":[{"count":4,"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/posts\/1836\/revisions"}],"predecessor-version":[{"id":4364,"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/posts\/1836\/revisions\/4364"}],"wp:attachment":[{"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/media?parent=1836"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/categories?post=1836"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.nodesign.net\/blog\/wp-json\/wp\/v2\/tags?post=1836"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}