De la simplicité…

Un des avantages de notre boulot est de croiser beaucoup contextes, de métiers, d’applications, de technologies, d’organisations et d’équipes différentes. Au travers de tous ces contextes, il reste au moins une chose commune : la simplicité ou plutôt son absence…


« Non mais là il nous faut de l’ajax, là » disait-elle…Cette réflexion résume à elle seule cette absence de simplicité qui mène inévitablement à un empilement de frameworks, à des choix d’outils complètement décorrélés de toute réalité ou surdimensionné par rapport aux besoins. Et oui! Les besoins, car tout est là. Ce qui a de la valeur pour le client – qu’il soit final, que ce soit une autre application, le reste du SI… – et donc, ce sur quoi il est important de se concentrer.

Imaginez une page web qui affiche simplement deux informations : votre solde de compte courant et si votre encours de CB vous met à découvert ou non. Simplissime.

L’approche technophile nous pousse à imaginer un système Web 2.0 Full Ajax home made avec le dernier framework, RESTFull, EDA mais CEP « aware » (vous ne comprenez pas ? normal ça ne veut pas vraiment dire quoique ce soit…). Formulé de façon plus compréhensive, à imaginer des systèmes mettant en œuvre les dernières technologies. Un besoin simple mais que dire de l’implémentation…

Une approche de ce même besoin centrée sur l’utilisateur nous offre un autre prisme et nous focalise sur deux points:
– affichage de la page en moins d’une seconde
– un rendu visuel permettant à l’utilisateur de voir en moins de 3 secondes si son encours de CB le met à découvert, ou pas…

Drivé par la valeur « pour le client », la solution devient une simple page affichant le solde et une image « vert, tout va bien », « rouge, découvert en vue »…pas suffisant? pas sûr. avec une bonne CSS et un joli design graphique.

Amazon est-il complexe? Indéniablement sur certains aspects de l’architecture des systèmes mais lorsqu’on lit un peu Werner Vogels, on se rend compte qu’Amazon combat la complexité et se bat pour conserver des systèmes « as simple as possible »:
« A very important point is whether candidates think the right way about customers and technology. Technology is useless if not used for the greater good of serving the customer. We are a strongly customer-oriented company, and we often use the “working from the customer backwards” approach. This means that in your thought process, you start with the customer and work your way backwards until you have found the simple and minimal technology that you need to satisfy the new customer requirement »

L’IHM d’amazon est-elle complexe, « Web 2.0 compliant »? non. Et a-t-elle moins de valeur? non. La valeur d’Amazon n’est pas dans l’animation Flash. Sa valeur repose dans la diversité du choix, la pertinence des algorithmes « les utilisateurs ayant acheté cet article ont aussi acheté… », la simplicité pour passer une commande, la fiabilité avec lesquels les colis arrivent (personnellement, une seule de mes commandes s’est perdue et il a suffit d’un mail pour que cette dernière reparte illico.)

D’autres organisations ont compris l’importance de cette approche « user centric » et en tire même un avantage concurrentiel :
– Apple et son iPhone qui répond uniquement au besoin de lecture et occulte volontairement celui de classer (depuis l’iPhone)
– Toyota – encore lui – a aligné la R&D sur les besoin des clients. Le marketing a ainsi détecté un vieillissement de la population japonaise et donc de nouvelles limitations (coordinations aléatoires, gestuelle limitée…) que la R&D s’est empressées de lever en fournissant une voiture qui se « gare toute seule ».

Recentrons-nous sur le besoin, ce qui est important pour le client et Le « KISS Principle » s’appliquera à merveille.
Et John Maeda de rajouter : « La simplicité, c’est supprimer le superficiel et rajouter ce qui a de la valeur »

Et si la simplicité devenait hype ?

6 commentaires sur “De la simplicité…”

  • Malheureusement, dans ton exemple de consultation de solde, cette page toute simple, oasis de sobriété, ne sera qu'une fonctionnalité "annexe", noyée entre les boutons qui clignotent et qui ouvrent respectivement : une fenêtre de chat avec son conseiller ; un simulateur permettant de savoir quel produit d'assurance-vie du partenaire Untel serait la plus adaptée à sa situation ; un wizard de souscription en ligne avec à chaque étape un trombone parlant qui détaille le rôle de chaque option ; etc. etc. Un peu de pessimisme ;-)
  • Tout dépend de ce qu'on appelle l'utilisateur. Si tu t'amuses à faire un truc trop compliqué quand on t'a demandé une petite page toute simple, tu te trompes d'utilisateur. Mais si tu proposes une page web à un gars qui t'a demandé une api appelable en remote, tu te trompes de la même manière. Il faut juste écouter son client, son vrai client.
  • @Thomas : est-ce que ces fonctionnalités périphériques ont de la "valeur" pour le client? pas évident ;-). c'est un peu comme l'iphone en fait non? :o) @gak : je ne suis pas sûr de te suivre ;-)
  • Je partage complètement ce point de vue. Il faut se concentrer sur l'utilisateur.
  • Tout à fait d'accord avec votre approche. Pour les citations, il y a aussi Saint-Exupéry "La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer" Pour l'implémentation, si on ajoute le DRY et le "Working Software over comprehensive documentation", c'est ce que nous (Aspectize) sommes en train d'essayer de faire dans le monde .Net.
  • C'est pourtant simple ... Tu décris un cas où il y a une grande différence entre ce qui est voulu et ce qui est produit. Pourquoi cette différence? Tu dis que c'est parce que l'architecte/développeur de service n'a pas su faire simple. A partir de maintenant on ne peut qu'extrapoler, mais le cas est assez fréquent pour permettre un peu d'imagination. Pourquoi le développement n'a-t-il pas su faire simple? C'est là que ça devient intéressant. Forcément, un technicien fera de la technique. On peut très bien supputer, de ce que tu racontes, qu'il n'avait pas en face de lui un interlocuteur pour le freiner et échanger assez pour comprendre le vrai besoin. Puisque le vrai besoin a été râté. Pourquoi? Parce que le besoin est mal défini? par exemple pour des raisons politiques. Ou pour parce qu'il a du temps pour ce projet et qu'il veut tester un truc (pour des raisons infinies...). Ou parce qu'il anticipe un truc.... Il y a plein de raisons pour dévier de ce qui est bien. Dire qu'on n'a pas su faire "ce qu'il fallait" c'est je pense se cacher la vraie raison. C'est oublier de continuer à se poser la question Lean : "Pourquoi?...". Dans ma première réponse j'ai simplement retourné ton propos (racontant le cas d'un développement simple, alors que le client voulait qqch de compliqué) parce que ce cas "inverse" est en réalité causé par les mêmes choses. bref...
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha