La qualité Web est souvent vue comme contraignante, compliquée, pénible, voire dans le pire des cas sclérosante. L’image type est celle du pavé indigeste au possible, genre un bon classeur de 30 kilos avec lequel on assomme le travailleur du Web.

C’est en fait selon moi tout le contraire : la qualité Web est une façon de faire sauter des verrous et un puissant levier d’amélioration. Évidemment, tout dépend de la manière d’aborder la question. Pour ma part, je l’aborde de manière très pratique et peu théorique.

Je vous propose donc un voyage au pays de la qualité Web, et comme pour tout voyage, nous aurons besoin d’un point de départ, d’une carte, de points intermédiaires et d’un but !

Précisions avant d’embarquer : les exemples et retours d’expérience que je vais donner sont tous réels. La manière de voir la qualité Web n’engage en revanche que moi. Précisons également que cette approche est à remplacer dans un contexte : l’agence Web a envie de commencer une démarche qualité, mais n’a pas du tout cette culture, ou du moins très peu.

Le point de départ et la carte

Toute réflexion a besoin d’un postulat de base, je pars donc de l’idée qu’on a une checklist qualité. Sauf que… au lieu de partir d’une checklist qui contient tout ce que l’on voudrait avoir dans un site parfait, je préfère partir d’une checklist qui ne contient que ce avec quoi on ne veut pas négocier : ce que l’on veut garder à tout prix ou ce que l’on ne veut oublier en aucun cas.

Pourquoi un tel postulat ?

Quand vous débarquez dans une boîte où tout le monde n’a pas la culture de la qualité Web, si vous arrivez avec une checklist de 250 critères, je peux vous prédire un résultat : vos collègues vont se braquer, voir la qualité Web comme un boulet, une punition, bref un fardeau qui risque d’être vite abandonné.

Concentrez-vous sur des objectifs raisonnablement atteignables, même et surtout si vous-même vous êtes déjà allé bien plus loin. Comme je l’indiquais ci-dessus, concentrez-vous sur ce que personne ne veut négocier : autant pour le chef qui veut présenter le site au client que pour le technicien qui veut être fier de son travail.

Cette façon d’aborder les choses sera moins douloureuse. Par exemple, ma checklist d’« avant-mise en production d’un site » contient une grosse trentaine de points. Même si, en tant qu’infatigable perfectionniste, je souhaiterais en mettre plus, cette base qui permet de contenter tout le monde est un point de démarrage satisfaisant, et elle a le mérite… de ne pas m’empêcher pour autant d’aller plus loin.

Les points intermédiaires

La fainéantise en tête

Quel est le premier bon réflexe à avoir en matière de travail ? Ne pas se fatiguer, très bonne réponse. Pour ne pas passer pour un fainéant, je dirais bien que celui qui veut voyager loin ménage sa monture… ok, assumons : j’aime être fainéant, comme environ 100% des gens. Par contre, par fainéantise, j’entends que j’aime bien travailler pour moins travailler.

Cela tombe bien : toujours dans l’esprit d’aborder la checklist de la manière la moins douloureuse possible, la première chose à faire est de chercher les points qui peuvent être traités de manière automatique.

Photo de Michel Mégard, sous licence CC-BY-SA

Un exemple : dans ma checklist, j’ai un point qui me dit que je dois activer la compression GZIP et activer la mise en cache. Or, pour peu que j’aie mis les bonnes directives dans mon fichier htaccess lors de précédents projets, ce point est traité de facto : pas besoin de réfléchir pour le traiter !

Non seulement cela me donne la sensation que ma checklist se réduit, mais en plus cela permet de libérer mon esprit pour d’autres choses.

Bien travailler pour moins travailler

La seconde étape est de voir ce qui nécessite un développement pour être automatisé. Un exemple : toujours dans ma checklist, une demande du SEO est d’éviter que le serveur de développement soit indexé.

Une réponse possible, volontairement simpliste : un simple if en PHP permet de le faire :

if ($condition_serveur_test == true) {
   echo '<meta name="robots" content="noindex, nofollow" />';
}
else { echo '<meta name="robots" content="index, follow" />';}

(c’est un exemple, évidemment, cela serait à améliorer grandement)

Une fois la solution trouvée a ce point de la checklist, ce dernier passe dans la colonne « traité automatiquement ». Encore un peu de sueur économisée !

Diminuer et répartir la charge

Je disais plus haut que celui qui veut voyager loin ménage sa monture. Là nous avons réduit le nombre de points à penser, toutefois, tout n’est pas automatisable. Il reste de plus le problème d’alléger le plus possible cette checklist de fin.

Comment diminuer la charge ? Si l’on peut croire que les quick wins sont terminés, c’est totalement faux. Il suffit juste de dispatcher les points non automatiques sur les divers checkpoints de votre projet. En d’autres termes : anticiper. Si vous préférez une expression très à la mode : prendre en amont.

Plusieurs cas : si comme moi vous êtes plus ou moins responsable de la qualité, vous savez à quels moments certains points peuvent être résolus dans l’organisation du travail.

Un exemple typique de point traitable rapidement : quand mon graphiste préféré me fournit les exports pour que je puisse commencer mon intégration, s’il l’a oublié, je lui demande tout de suite de produire les icônes de favori (favicon.ico et apple-touch-icon.png pour ne pas les citer). Deux avantages :

• il est encore la tête dans ce projet, donc cela le dérangera moins de s’en occuper de suite plutôt que d’être forcé d’y revenir à la fin du projet, où il aura sûrement commencé autre chose,
• et cela fait un point de traité encore !

Un autre exemple : toujours dans ma checklist qualité, j’ai un point qui me dit que je dois prévoir une adaptation des contenus pour l’impression, une CSS print en somme. Si les maquettes sont suffisamment précises… je peux faire cette étape au moment de l’intégration. Dans le cas contraire, je peux quand même préparer cette adaptation ! Ainsi, cela me permettra de limiter les risques de surprise : si une version print d’une page a un problème, je peux raisonnablement penser que le problème viendra du contenu de cette page et non du gabarit en lui-même.

Ajoutons à cela que l’environnement de travail permet également de limiter ces risques : typiquement si mon framework CSS a une batterie de classes qui permet d’éviter les dépassements, il contribue de facto à la réalisation de ce point.

Autrement dit, 90 à 95% de ce point de ma checklist peut déjà être traité à la fin de l’intégration, avant même que les contenus ne soient insérés.

La préparation de l’arrivée

Comme dans tout voyage, l’arrivée suscite une certaine excitation, mais c’est plus souvent du stress qu’autre chose : peu de temps, beaucoup de demandes, un autre projet qui s’annonce, etc. Sauf… si bien sûr la checklist a été suffisamment réduite comme expliqué ci-dessus.

Ajoutons que la prise en amont de tous les points qui peuvent l’être transformera radicalement la vision du check final : de boulet qu’on traîne et qu’on doit résoudre en urgence, il devient subitement une simple étape, parfois même une simple formalité très satisfaisante.

Bilan du voyage

Les avantages

L’avantage de voir la qualité de manière positive et maîtrisée, c’est qu’elle est diablement stimulante !

Dites à un intégrateur « tiens on a fini le site, merde, fais vite une version print des contenus et dépêche-toi on est à la bourre », vous allez le stresser et le contraindre. Dites-lui avant qu’il commence son template, « tiens, pense bien à faire une version print dès le template, comme ça tu as le temps de bien faire », et il stressera beaucoup moins.

Ajoutons à cela que le fait de résoudre l’automatisation d’un point est souvent plus amusante que la résolution du point proprement dite : les informaticiens sont de grands joueurs toujours prompts à relever un défi ! Il m’arrive parfois de prendre trois heures pour programmer une routine qui pourrait être faite manuellement en une demi-heure. Néanmoins, si ces trois heures me permettent de gagner un quart d’heure à chaque fois, ce n’est pas une perte de temps, mais juste du temps investi.

Fonctionner ainsi met la qualité Web en moteur de l’amélioration, et non en frein quand on la pratique a posteriori. C’est de l’amélioration continue.

Si vous avez besoin de plus contrôler la chaine de production, une idée serait de poser des mini-checklists aux grandes étapes du projet, soit dérivées des checklists principales, soit des « points de contrôles partiels ». Combinez cette idée avec des checklists métiers, et les différents intervenants vont voir leur checklist encore diminuer. Pour peu que votre équipe se dote d’outils très puissants comme Opquast Desktop, elle sera solidement armée !

Pour ma part, je pars de l’idée qu’il n’y a pas plus expert pour s’organiser que l’expert concerné par le point de la checklist : il sait comment il travaille, donc il est le plus apte à le résoudre. La seule aide dont il peut avoir besoin est une prise de conscience que la checklist diluée au long du projet est une moindre contrainte, et éventuellement un peu de méthode si l’organisation est un peu brouillonne.

Parenthèse : effectivement, cela suppose une prise de responsabilité. Toutefois, selon moi, on ne peut se prétendre expert et professionnel de son domaine si on n’a pas intégré la qualité dont on est responsable. Tant pis pour le froissage d’ego.

Semer pour le prochain voyage

La destination importe moins que le chemin parcouru.

Derrière ce proverbe connu se cache le cycle de la qualité Web : une fois votre checklist maîtrisée et transformée en réflexes, rien ne vous bloque pour inclure de nouveaux points. J’ai parlé plus haut de ne pas se gêner pour tester et aller un peu plus loin : cela vous permettra de préparer le terrain pour vos prochaines réalisations. À force de semer les futurs points que vous souhaitez prendre en compte, il y a une grande chance que ces derniers soient repris lors de prochains projets. Cette idée est très bien expliquée dans l’article de Luc Poupard, les petits ruisseaux font les grandes rivières.

Arrivera un moment où vous pourrez proposer d’inclure ce point dans votre checklist, et cela passera comme une lettre à la poste, vous entendrez probablement une remarque du genre « ouais on a l’habitude, pas de souci ». Avouez que cela change d’un développeur qui freine des quatre fers ! 🙂

Qu’on se le dise, la mise en place de la qualité est une course de fond : cela prend du temps. Privilégier une lente mais sûre montée en puissance permet d’éviter de nombreuses frustrations chez les débutants, et de ménager celles des personnes plus avancées sur le sujet. Néanmoins, cela ne doit pas vous empêcher d’avoir in fine l’objectif suivant : que votre checklist ne contienne plus seulement ce que vous ne voulez pas négocier mais enfin tout ce que vous voudrez pour un site « parfait ».

En conclusion

Comme vous avez pu le voir, un simple changement de dogme et quelques idées pratiques permettent de faire exploser le mythe de la qualité Web pénible à mettre en place. Rien n’est plus faux : c’est un des leviers les plus puissants qui soient, et ce levier est là pour faire sauter des verrous.

Bien abordée, cela peut même être le moteur principal de l’amélioration de vos prestations. En sortant même du cadre des réalisations, ce sont même avant tout les personnes de l’équipe qui se valoriseront, et cela, ça n’a pas de prix.

Gagner toutes vos batailles n’est pas la meilleure chose ; l’excellence suprême consiste à gagner sans combattre.

Le but du jeu est, pour reprendre la métaphore du voyage, de lancer le train d’amélioration : une fois que votre équipe aura pris goût à se faire plaisir ainsi, vous pourrez viser d’autres destinations plus difficiles et aller plus loin. Votre équipe pourrait même choisir de vous emmener plus loin sans que vous ayez besoin d’être la locomotive.