À mesure que le web gagne en maturité, les exigences des clients sur les sites et les projets livrés deviennent de plus en plus importantes. Au point d’avoir, depuis au moins deux ans, atteint sinon dépassé les exigences de design, ergonomie et stabilité autrefois réservées aux seuls éditeurs de logiciels. Dans un premier temps apparaître comme un point particulièrement positif, preuve que le web a gagné en maturité et cessé d’être un terrain de jeu pour innovateurs frappé d’un certain jeunisme, à la fois par les expérimentations parfois catastrophiques de la première bulle Internet, et par un soucis de qualité souvent au rabais. Cependant, cette exigence, venue à la fois des clients et des utilisateurs, a pour nous professionnels du web des impacts non négligeables et crée des problématiques avec lesquelles il nous faut apprendre à composer, l’imputation des problèmes étant souvent à sens unique quand les solutions à apporter sont clairement multilatérales.

Quelles raisons à cela ?

Les raisons à cela sont nombreuses, à la fois d’ordre ergonomiques, technique et marketing, ces deux dernières ayant parfois (souvent) tendance à se recouper.

Contrairement à un logiciel du commerce dont l’interface est avant tout fonctionnelle, un site ou une application web est aujourd’hui le principal vecteur d’image de la société qui le publie. Cela a évidemment un impact certain en termes de graphisme. Ce dernier doit à la fois être attractif pour le visiteur tout en transmettant au premier coup d’oeil les valeurs essentielles de l’entreprise, et en favorisant l’acte d’achat quel qu’il soit. On assiste ainsi à des exigences de calage proches de celle qu’on rencontre dans le monde de l’impression, mais avec des contraintes techniques beaucoup plus importantes. Il s’agit en effet de prendre en considération la multitude de navigateurs disposant de nombreux moteurs tous différents et loin d’être compatibles, que ce soit au niveau du rendu, ou même des instructions supportées. Les différences de rendu, même minimes, sont de moins en moins bien acceptées, alors même que le panel de navigateurs types annoncé en avant-vente s’accroît : Internet Explorer 6 et 7, les versions 5 ayant heureusement fini par disparaître, Mozilla Firefox, Opéra et Safari quand la liste n’est pas plus exhaustive. L’élargissement de cette dernière est certes positive, car elle dénote une diversification des usages et la prise en compte au niveau client des navigateurs dit alternatifs, multiplie cependant les difficultés techniques, surtout si l’on cherche, pour des raisons évidentes de compatibilité ascendante, à ne pas utiliser de hacks ou de feuilles de style conditionnelles. Après la multiplication des navigateurs, on assiste en effet à la multiplication des terminaux, et il est de plus en plus urgent de faire pour soi la recommandation principale de l’Initiative Web Mobile du W3C : développer pour un seul web (one web to rule them all).

Cela a également un impact important en termes de positionnement sur les outils de recherche, en dehors de toutes considérations d’achat de mots clé. Les clients s’attendent désormais à obtenir clé en main un site optimisé pour le référencement naturel, et, contrairement à ce qu’on voit encore beaucoup sur le marché, cela ne se contente pas d’un relookage de façade exécuté à grands frais par des sociétés de référencement aux résultats souvent douteux. L’optimisation d’un site pour les outils de recherche se fait dès la conception, et passe par la mise en pratique d’un certain nombre de règles écrites et connues. Cela passe par une arborescence peu profonde, des contenus réellement pertinents, et une utilisation correcte, c’est à dire finalement normale du balisage (X)HTML. On remarquera au passage qu’un site optimisé pour Google ne doit pas être un site fait pour Google, mais bien pour les utilisateurs présents et à venir, et là aussi, les règles sont connues. À contrario, on peut se réjouir que, dans un sens, cette sur optimisation ait des effets bénéfiques en termes d’accessibilité, parent pauvre du web, et que devraient aussi systématiquement concerner les exigences aussi bien des clients que des utilisateurs.

Et parlant des utilisateurs, ce sont souvent eux, bien plus que le client, qui sont les meilleurs juges du niveau de qualité, acceptable ou non, d’un site ou d’une application web. C’est tout d’abord le signe, important, que le web est vraiment rentré dans les usages. À ce titre, des expressions comme “don’t make me think”, ou “internet, donne moi ce que je veux !” prennent tout leur sens. Je rejoins tout à fait Myriam Lorant qui rappelait lors de sa conférence à Paris Web 2007 que pour l’utilisateur, internet est avant tout un outil de recherche, même si je trouve cette définition trop restrictive. Elle résume cependant parfaitement le comportement de l’utilisateur moyen au mois de décembre 2007. Ce dernier vient sur le web avec un besoin précis, et entend le résoudre vite, et surtout de la manière dont il s’attend à le résoudre. L’ère de l’utilisateur prêt à recommencer trois fois une manipulation d’une dizaine d’écrans pour commander un simple billet de train est révolue, même s’il reste beaucoup à faire. À ce titre, la différence de parcours d’achat entre le site de la SNCF et les bornes en gare est phénoménale, mais ce n’est pas mon propos, et j’y consacrerai bientôt un billet. Toujours est-il que les sites deviennent de plus en plus ciblés, marketing vertical, et à cet effet, les tests sur les populations d’utilisateurs définis vont prendre de plus en plus d’importance dans les mois et les années à venir, du moins peut-on l’espérer. Les études empiriques menant à des désastre de positionnement comme celui qu’on a pu voir au moment du lancement de la Twingo – une voiture conçue pour les vieux à produire en peu d’exemplaires devenue la coqueluche et le symbole d’une génération de jeunes conducteur – sans considération aucune quant à la réussite globale du projet en termes de ventes, ne doivent plus se produire. La fréquentation d’un site, et les taux de transformation sont aujourd’hui des facteurs clé dans les considérations de réussite d’un projet, bien plus que le design ou les fonctionnalités. Cela montre d’ailleurs un changement important dans les mentalités des clients : même s’il reste au coeur du projet, le site n’est plus une fin en soi, mais une composante d’une stratégie online globale, qu’elle soit business ou marketing. De nombreuses agences se limitant aujourd’hui à fournir des outils – certes de qualité – devront rapidement se repositionner, sous peine de se faire dépasser par un marché en constante mutation.

Des cas pas toujours gérables

À une époque pas si éloignée, les problèmes de qualité relevés par les clients tournaient principalement autour de deux centres névralgiques : le bug fonctionnel et le calage grpahique. À mesure que les sites web deviennent plus complexes et relèvent de plus en plus du logiciel, on aurait pu croire que les bugs fonctionnels prendraient largement le pas sur le reste des considérations. C’était évidemment sans compter le changement de position des clients vis à vis du web, au point que la résolution de ces deux scopes parait désormais normale, et c’est tant mieux, les préoccupations majeures devenant toutes autres.

D’abord, une optimisation des contenus, et de leur affichage. Il s’agit d’abord pour le visiteur d’accéder à un maximum de contenu au dessus de la ligne de flottaison de l’écran, même si, cela n’est plus à prouver, les utilisateurs scrollent. Il s’agit ensuite d’être incitatif : donner envie de rester, dans un premier temps, puis de visiter, et enfin – et surtout – d’acheter. Quand on voit que le temps de transformation, entre la première arrivée d’un visiteur sur un site, et l’acte d’achat lui même atteint en moyenne 38 heures, on comprend facilement l’importance de cette fidélisation. À cet effet, l’intervention de professionnels de la rédaction tend à se développer. Non seulement afin de produire du contenu attractif, mais encore du contenu propre à traduire le positionnement et les valeurs du client, ce qui n’est pas toujours évident.
Ensuite, par une optimisation du parcours utilisateur. Cela passe, comme on l’a dit, par la connaissance du public ciblé, en fonction du résultat à obtenir. Sur un site de e-commerce, par exemple, le nombre moyen d’étapes d’achat optimal varie en fonction du prix d’achat des articles. Cela passe d’une part par une spécialisation des consultants en charge de la conception fonctionnelle des sites et des applications, pour lesquels la connaissance du métier de leur client devient peu à peu indispensable, mais également, et c’est bien, par un réel placement de l’utilisateur au centre des choses, là où l’on avait tendance mettre les processus.

On voit aujourd’hui apparaître des cas de plus en plus inhabituels, dont certains ne sont pas du ressort du développement web. C’est le cas notamment du bouton “back” du navigateur. Il faut savoir que ce dernier est le plus utilisé par les internautes, plus même que la barre d’URL ou que la barre de recherche Google. On peut parfois observer des différences de comportement à l’action du bouton de retour arrière en fonction des modèles, et des versions, de navigateurs, donnant de plus en plus souvent lieu à l’angoissante question “pourquoi quand je clique sur back ça…” Je pourrais parler du bonton back du navigateur durant un billet entier, et celui-ci est déjà suffisamment long, mais il me semble cependant important de signaler qu’en termes d’usages, la généralisation des pages full AJAX sur de nombreux sites, sans qu’il soit question ni de graceful degradation, ni de progressive enhancement, ne s’est pas accompagnée d’un abandon du bouton “back” pour autant. Cela montre d’ailleurs bien que la technologie a largement été dépassée par les usages, et l’on ne peut que s’en féliciter. Il n’est pas interdit de s’imaginer qu’à terme, on aille vers des applications à la Prism, dépourvues d’un retour arrière devenu inutile, mais ce n’est pas le cas. Désactivez le bouton back sur votre site ou application, et croyez-moi, vous entendrez hurler vos utilisateurs. La prise en compte de ce genre de “détails” devient donc une composante importante lors des finitions d’un site ou d’une application, malheureusement, on ne peut prévoir à chaque instant ce qu’un clic sur ce bouton lors d’un parcours utilisateur, ou après avoir quitté le site via la barre d’URL pourra avoir aussi bien en termes d’affichage que d’intégrité des données.

Une éducation indispensable

La qualité, oui, mais pas à n’importe quel prix, ni n’importe comment. Et cela passe d’abord par l’éducation du client, mais également des équipes de développement. Chacun doit faire des efforts, financier ou dans ses pratiques, afin de délivrer le meilleur.

Pour le client, il s’agit avant-tout de comprendre que la qualité a un prix. Si un projet se définit par le triptyque coût / qualité / temps, il faut bien comprendre qu’il est impossible d’avoir les trois. On peut faire un site vite et pas cher, mais il ne faut pas espérer de qualité en retours, de même qu’on peut rajouter de la qualité, mais il faut soit rajouter du temps, soit du budget, soit, le cas échéant, les deux. À vous donc d’éduquer le client dans ce sens, notamment en lui faisant comprendre qu’on ne produit pas un web de qualité avec des délais au lance-pierre. On peut certes parallelliser certaines tâches, dès lors qu’elles n’empiètent pas les unes sur les autres. Il faut prévoir des temps de recette en adéquation avec la complexité du projet, et ce dès l’avant-vente, ce qui implique une compréhension claire du projet à priori. Pas toujours évident, pas plus que le gel définitif des spécifications avant développement dont je parlais il n’y a pas si longtemps.

Une meilleure qualité passe également par la mise en place de processus et de bonnes pratiques en interne, même si elles peuvent sembler inutiles ou stupides à première vue. À commencer d’ailleurs par la systématisation de méthodes de test driven development, dans lesquelles les tests automatisés sont écrits avant les développements, ces derniers devant valider à posteriori. Certes il s’agit d’un processus long et coûteux, mais qui permet d’éviter les régressions, et compense souvent lors de la recette le temps investi. Il demande surtout de prendre de bonnes habitudes et d’en perdre de mauvaises, ce qui n’est jamais facile.

Il est également particulièrement important de ne pas prendre la phase de recette à la légère, que ce soit en interne ou chez le client, et, là aussi, une démarche d’éducation peut être nécessaire. Cela passe d’abord par la mise en place de processus définis, et ensuite seulement, par l’utilisation d’outils permettant d’en faciliter l’exécution. Parmi les bonnes pratiques, passent la fourniture d’informations complètes quant au bug rencontré : nature, gravité, description, et surtout, étapes nécessaires à sa reproduction, éventuellement screenshot à l’appui. Inutile de demander au client de toujours chercher à reproduire un bug avant de l’escalader, il ne le fera jamais tout en affirmant être passé par cette étape. L’autre étape fondamentale est la qualification des incidents remontés par une personne unique ayant une vue globale du projet : enjeux, échéances, périmètre technique et fonctionnel, mais également évaluation du temps de développement nécessaire et connaissance de l’équipe, afin d’en optimiser l’affectation et éventuellement orienter les développeurs. Cette répartition technique des bugs vient en aval du travail du chef de projets à qui revient la mission de déterminer ce qui relève du bug et ce qui relève de l’évolution. Restent les outils à mettre en place, et là, les exemples ne manquent pas : Trac, Jira, Bugzilla ou Redmine, auquel va ma préférence, à la fois pour le langage dans lequel il a été développé – Ruby on Rails – mais également pour les nombreuses fonctionnalités qu’il offre tout en étant largement accessible au client final. À l’aube de 2008, sur le web, continuer de gérer ses recettes dans un fichier Excel me semble, à bien des égards, inimaginable.

Conclusion

Comme on a pu le voir, la hausse des exigences en termes de qualité des clients et des utilisateurs n’est pas du tout un problème à rejeter de manière unilatérale sur les professionnels du web. Les clients ont des soucis d’image, le web étant devenu une composante d’une stratégie beaucoup plus globale de business ou de marketing en ligne. Les utilisateurs ont maintenant pris des habitudes et entendent recevoir une certaine qualité de service. Cette qualité a un coût, à la fois financier et humain dont les clients et les agences doivent bien comprendre la portée. Cela passe donc par des budgets adaptés aux exigences finales d’une part, et à la mise à disposition des projets de ressources à la fois qualifiées et en nombre suffisant. Et dans l’éternelle tentative de résolution de l’équation coût / qualité / temps, l’outsourcing est loin d’être la panacée.

Ne perdons pas la boule

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: