Je me suis souvent posé tout un tas de question sur l’éloge -souvent justifiée- de la simplicité, en particulier dans le domaine des nouvelles technologies. Petite compilation des notes que j’ai pu prendre sur ce sujet….
L’épure dans l’interface utilisateur
Google et Apple, chacun à leur manière, représentent les écoles les plus connues de l’épure d’IHM. La page d’accueil de Google est le parfait exemple de l’épure ultime, même s’il s’agit un peu de l’arbre qui cache la forêt : dans les faits, on sait que peu de gens passent aujourd’hui par la page d’accueil de Google, préférant les barres d’outils, ou les champs de recherche intégrés dans divers sites.
Toujours est il que le succès initial de Google est en partie dû à sa page d’accueil légendairement simple, et qui est le meilleur acte de foi de la société : “notre métier, c’est la recherche”. Vu la forme tentaculaire que prend Google ces derniers temps, ce postulat peut prêter à sourire, mais l’idée est restée gravée : Google, c’est simple.
Les sites étiquettés “Web 2.0” sont restés le plus souvent dans cette même lignée. Fini les looks surchargés de la fin des années 90, un site Web doit être, au moins en apparence, d’une simplicité extrême.
Un exemple parmi plein d’autres : le site de l’éditeur du logiciel Coda. Le produit n’est pourtant pas d’une simplicité extrême (il est destiné à des développeurs), mais sa présentation est très épurée.
L’épure dans l’analyse fonctionnelle
L’exemple le plus flagrant d’épure fonctionnelle est sans doute le site Twitter. Non seulement il s’agit d’un des sites les plus simples en termes de fonctionnalités (je fais régulièrement “refaire” le site par des étudiants débutants en développement Web), mais, au delà de ça, toute sa puissance vient de cette simplicité qui est devenu un vrai moyen pour ses utilisateurs de “s’approprier” le site, en détournant certains fonctionnements ou en inventant d’autres (la notion de “ReTweet”, par exemple, consistant simplement à mentionner “RT” devant un message pour montrer qu’on retransmet le message de quelqu’un d’autre).
Curieux paradigme : plus un site est simple, mais ouvert (Twitter est réputé pour son API permettant à de nombreux sites et applications de graviter autour de son écosystème), plus l’appropriation, et la richesse, qu’en font ses utilisateurs au final est importante ?
L’épure dans le discours marketing
Je vais encore une fois revenir sur l’exemple Apple, cette fois-ci avec les gammes d’iPod.
Avant les iPod, et longtemps après également, la plupart des baladeurs nécessitaient d’acquérir un minimum de compétences techniques :
- il fallait connaître la notion de taille, en Mo, Go….
- il fallait connaître la différence entre ce qu’était un baladeur à disque dur, d’un baladeur à mémoire Flash, etc…
Les iPod, comme tous les autres baladeurs, sont dépendants des progrès des constructeurs d’électronique. En 2004, par exemple, l’iPod mini utilisait un tout petit disque dur d’1,8 pouce. Lorsque les capacités et les coûts d’une mémoire Flash ont atteint des seuils suffisants, Apple a pu lancer le projet d’iPod nano, qui n’était rien d’autre qu’un iPod mini avec de la mémoire Flash, et donc forcément bien plus petit.
Ca, c’est la technique. Mais pour le discours commercial, rien de tout cela. A part les technophiles, personne ne sait ce qu’il y a à l’intérieur d’un iPod. Ils ont à leur disposition des gammes de prix, et des noms commerciaux facilement mémorisables (Shuffle, nano, Classic, Touch).
Cette pratique, basée sur le fait que l’utilisateur n’a pas à connaitre les éléments techniques favorisant leur choix, détonait énormément par rapport aux concurrents, qui utilisaient tous des sigles un peu obscurs, style MF-128Mo+.
Inutile de dire que cette façon de procéder a contribué de manière non négligeable au succès des iPod. Elle a toutefois ses limites : Jobs a également tenté de supprimer toute notion ou presque de capacité mémoire, en quantifiant un baladeur MP3 à partir du nombre de chansons qu’il peut stocker. Le premier iPod permettait de stocker 1500 chansons, les plus récents 30 000 ou 60 000. Une chanson était arbitrairement considérée comme représentant 3 à 4 mégaoctets.
Cette “simplification” n’a jamais réellement fonctionné, tout d’abord parce que le grand public s’est familiarisé, même sans forcément vraiment le comprendre, les notion de méga-octet, giga-octet… L’autre raison était d’ordre pratique : petit à petit, les baladeurs embarquèrent autre chose que de la musique : des photos, de la vidéo, des jeux… La “mesure-étalon” chanson n’avait donc plus court.
L’épure dans la conception technique
Je me souviens, en tant que développeur Java, de l’époque où Sun lançait son offre “J2EE”, basée en bonne partie sur la notion d’Enterprise Java Beans. Une vraie révolution dans la façon de voir la gestion des données. Mais aussi une usine à gaz inaccessible pour 99% des développeurs de l’époque : un investissement en temps beaucoup trop important était nécessaire pour arriver à une maitrise fragile du concept. Et surtout, des applications très difficilement maintenable, puisque liée à une technologie complexe et peu répandue.
Ces EJB ont été une aubaine. Pas pour eux même, puisqu’ils sont restés confidentiels. Mais dans le contre pouvoir qu’ils ont amené. Quelques développeurs ont été excités par l’idée d’exploiter d’une manière différente les données au sein d’une application. Et, en même temps, ont été très décontenancés la façon de concevoir un objet. C’est l’époque des objets “KISS” (Keep it Simple Stupid) : des classes simples, faciles à comprendre, faciles à manipuler, faciles à modifier. Une base simplissime, mais qui permet au développeur d’effectuer des choses complexes. Parce qu’il y a un “point d’entrée” accessible pour ceux qui découvrent l’architecture. Parce que les bases sont simples et donc maitrisables.
Ironiquement, la philosophie “KISS” a été la base de bibliothèques sans cesse plus évoluées, et qui ont petit à petit ramené énormément de complexité… D’où l’autre principe que j’essaie de ne jamais oublier, avec celui de la simplicité : Back to basics ! 🙂