Des applications web simples nécessitent avant tout des processus simples

Quand j’explique à un non initié ce que je fais chez blueKiwi Software, la première question qu’ils me posent est quasi systématiquement “quelle est la différence entre un site et une application web”. La réponse pourrait donner lieu à un billet à elle seule, celle que je donne est beaucoup plus courte, et pas toujours plus explicite : un site web a pour objectif de délivrer du contenu, une application web de mettre en place les processus qui vont amener à la délivrance de ce contenu, sans généralement tenir compte de la nature de ce dernier.

Le même béotien, après m’avoir confondu avec le service clients d’un vendeur de PC et m’avoir demandé de réparer son ordinateur qui n’imprime plus à cause d’Henry qui a mis un virus d’Internet dedans – désolé choupette mais je suis sous Mac, Windows je ne connais pas – me demande généralement pourquoi l’informatique c’est si compliqué. Par informatique, il parle généralement de l’utilisation quotidienne de son système d’exploitation, de son traitement de textes, de son navigateur internet et de son logiciel de retouches photos qui lui permet de les mettre sur Internet.

Bien que ma description soit quelque peu caricaturale, et encore pas tant que cela, la question ne manque pas d’intérêt. Qu’est-ce qui différencie un outil Google ou un produit Apple des logiciels que j’utilise quotidiennement dans mon travail, ou, pire encore, des applications métier développées en interne ? Généralement deux choses : le nombre de fonctionnalités offertes et les processus pour les mettre en oeuvre.

KISS : Keep It Stupid Simple

Tout le monde n’est pas Google et leur modèle simple jusqu’à l’austérité ne peut évidemment pas s’appliquer à tout le monde. Il se base sur un principe bien connu mais jamais assez appliqué : le chemin le plus court entre deux points est la ligne droite… à condition évidemment que les deux points soient l’un en face de l’autre :

<li>Je saisis ma recherche.</li>
<li>Je clique.</li>
<li>J'ai mes réponses, et uniquement mes réponses.</li>

Ce dernier point est certainement le plus important : avant la recherche, Google n’affiche que son formulaire, après la recherche, il ne rajoute que ses résultats. Rien ne vient déranger l’utilisateur de ce pour quoi il vient – chercher – comme le font la très grande majorité des concurrents qui relèvent souvent plus du portail d’information que du moteur de recherche.

À contrario, les applications métier dans les entreprises sont là pour concrétiser de processus mis en place – souvent – en dépit du bon sens, en tout cas presque jamais en corrélation avec la nature des outils qui vont devoir les mettre en application. On se retrouve alors avec des workflow d’une extrême complexité faisant intervenir de manière impérative un très grand nombre d’intervenants, dont l’absence de validation bloque l’ensemble du processus. Il est d’ailleurs amusant de voir que souvent, en fin de conception, le client se rendant compte de l’aberration logicielle qu’il est en train de créer finisse par demander la mise en place d’une porte de sortie afin de pallier l’absence d’un maillon de la chaîne : le débrayage pur et simple des structures de contrôle qui font le workflow qu’il a tant de peine à mettre en place.

Les raisons d’une telle complexité sont multiples, mais l’expérience m’en a principalement fait rencontrer trois :

<li>Politiques : aucun des maillons de la chaîne ne doit être laissé de coté de peur de froisser les ego. Symptomatique des grandes entreprises françaises traditionnelles, et plus particulièrement des entreprises publiques dans lesquelles pour discuter avec quelqu'un se trouvant hiérarchiquement à mon niveau, mais dans un service différent, je suis obligé de remonter jusqu'à notre premier n+x commun avant de refaire toute la descente.</li>
<li>La peur : les processus les plus compliqués sont souvent dus à une volonté de contrôle extrême des actions des collaborateurs sur l'ensemble de la chaîne.</li>
<li>La perte du réel : combien de processus géniaux sont-ils créés par des consultants externes à des années lumières des dures réalités de l'opérationnel? Probablement la majorité, et ces designers se tiennent toujours le plus loin possible du vieux proverbe "eat your own dog food". Ils n'ont quasiment aucune chance d'utiliser un jour leur merveilleuse création.</li>
<li>Après, il reste la possibilité que le processus ait été défini aux dés lors d'une partie de <em>l'ivre dont vous êtes le Éros</em>, mais cela n'arrive évidemment jamais.</li>

Less is more

Je vais vous faire un aveux, je suis strictement incapable d’utiliser un logiciel de la suite Office de Word de manière satisfaisante, au point d’avoir du demander à mon beau-frère d’aider mon épouse à réaliser son Powerpoint de fin d’études. La raison en est simple : il y a trop de fonctionnalités partout, on peut faire trop de trucs, et je suis incapable de m’y retrouver. Je me souviens en particulier de journées de galère passées à essayer de comprendre comment encadrer un titre sous Word 2 en n’encadrant que le texte et pas tous les caractères à la fois.

Les application (web ou non) sont généralement créées afin de remplir le plus grand nombre de fonctions possibles, bien au delà de la résolution du processus pour lequel elles sont initialement prévues. Sans vouloir rentrer dans une généralité, la raison en est simple : on ne peut jamais savoir à l’avance de quoi auront besoin les utilisateurs, aussi rajoute-t-on tout ce à quoi on peut penser, au détriment de l’utilisabilité. J’ai rencontré ce problème au moment de la mise en place d’un éditeur riche pour Typo : je le voulais le plus complet possible tout en bridant au maximum la créativité de l’utilisateur afin de l’empêcher de bloguer en rose sur fond vert. Mission accomplie après un certain nombre de tâtonnements.

Dans ses produits, Apple prend l’exact contre pied de ses clients. Plutôt que de se demander de quoi ses utilisateurs vont avoir besoin dans un hypothétique futur, les designers de Cupertino décident de cela pour eux et limitent donc volontairement les fonctionnalités à l’essentiel. C’est très frustrant pour un power user, et je me heurte constamment à des fonctionnalités avancées inexistantes ou, dans le meilleur des cas, non documentées. Cela a pourtant du bon : je dois réapprendre à penser, différemment, et à brider ma créativité. Une fois passé le premier moment de frustration, je me suis rendu compte que cette simplification me rendait bien plus productif.

Une application utile est une application utilisable et utilisée

Ce n’est pas un secret, une application trop complexe, que ce soit du point de vue des processus à mettre en application ou des fonctionnalités connaîtra toujours un taux d’adoption plus faible qu’une application plus simple et moins riche. Pour déterminer au premier coup d’oeil le niveau de complexité d’une application web, jetez un coup d’oeil au formulaire d’inscription, il est souvent symptomatique de ce que vous allez trouver derrière, au point que je renonce à tester un service web sur deux à cause d’un tel formulaire trop rebutant.