Je suis en train de lire Qualité Web, le livre (une note de lecture arrivera dès que je l'aurai fini), et je voulais partager quelques réflexions sur la manière de déployer et d'améliorer la qualité dans ma méthode de travail (d'intégrateur principalement).

J'apprécie beaucoup la lecture reposée de livres même à l'heure du tout numérique, car cela vous invite à sortir la tête du guidon même si votre gestion de la qualité est très artisanale, en tout cas, c'est comme cela que je vois la mienne, et elle me convient bien pour l'instant.

Le premier réflexe à prendre est déjà d'avoir une idée de la qualité que vous produisez… ou de la non-qualité. Eh oui, certains détestent l'idée d'un référentiel, mais c'est déjà bien de fixer une échelle, et de savoir à quel barreau on se situe sur cette échelle.

Pour certains points, c'est assez facile : si je veux regarder la validité de mon code, toc, un coup de validateur, et j'ai une bonne idée de ce que je dois améliorer.

Toutefois, pour d'autres domaines, c'est plus difficile : comment juger de la qualité de mon code désormais valide ? Là, cela demande beaucoup plus d'efforts :

• Est-ce que la structure est logique ?
• Est-il accessible ?
• Est-il performant ?
• Passe-t-il sur tous les navigateurs ?
• Etc.

Là, vous voyez le problème : il me faut une quantité de connaissances et d'expérience bien plus grande que pour le point précédent. Donc quand vous vous intéressez à la qualité, premier point d'importance selon moi : il faut être curieux et faire beaucoup de veille dans les domaines connexes. Et vous avez de la chance, en tant qu'intégrateur, énormément de domaines transitent par vous !

Une fois que la machine est lancée, vous allez vouloir améliorer vos productions. Donc il faut inclure ces connaissances dans votre travail. Deux cas de figure (en schématisant un peu) :

• Soit le point est une simple brique à ajouter : par exemple, je veux ajouter la compression serveur sur certains éléments, je dois ajouter ces lignes dans mon htaccess.
• Soit il faut repenser votre manière de travailler : ok, j'ai activé la compression, mais les CSS que je produis sont quand même trop lourdes, il faut que j'apprenne à faire des CSS plus légères.

Si le premier point est ce qu'on appelle en anglais un quick win (gain rapide), le second implique de nouvelles connaissances et de la pratique. Deuxième point, il faut accepter de lâcher prise et de se remettre en cause pour réfléchir à ce qu'on produit, et comment faire pour intégrer les nouveautés.

Après, la bonne idée sera de se dire : « ok, j'ai appris plein de trucs et amélioré des points, il faut que cela devienne un standard dans mon travail ». Parce que c'est bien, et surtout pour capitaliser ces efforts (et par simple fainéantise aussi en ce qui me concerne). Là, il faudra réfléchir à comment inclure ces points en standard dans votre méthode sans que cela ne soit mortellement chronophage.

Dans le cas de la « simple brique », vous pouvez l'inclure dans votre base de départ, ainsi c'est compris automatiquement. Après, il y a des arbitrages à faire, tant qu'un point demande trop de temps à être inclus et bouffe votre productivité, c'est que :

• Soit vous n'avez pas assez de connaissances pour le maitriser, et donc il faut approfondir,
• Soit la méthode d'inclusion n'est pas au point, et donc il faut acquérir plus de connaissances,
• Soit il faut repenser la méthode (ou alors, il y a un manque de pratique qui fait que les automatismes ne sont pas encore… automatiques).

Pratique, connaissances, tout cela prend du temps, cela ne se fait pas en 10 minutes. Troisième point, il faut voir pour inclure en standard les points que vous avez développés de manière aussi peu chronophage que possible. Donc, de la pratique, beaucoup de pratique pour que cela devienne un réflexe. « Champ de formulaire ? Je mets un label ! »

En parallèle, vous continuez à apprendre des choses, cela nourrit votre standard de base.

Arrive un moment, après beaucoup de pratique et d'amélioration, faites quelques projets, et ne pensez pas évaluation, fonctionnez à l'instinct avec vos habitudes. Une fois le travail fini, regardez l'échelle du début, et comparez là où vous étiez et là où vous êtes avec votre méthode de travail standard. Là, vous mesurerez le chemin parcouru, vous aurez peut-être même complètement dépassé votre échelle.

Et là, deux choses l'une, soit votre échelle est toujours valable, et il faut aller chercher les derniers échelons, soit votre échelle n'est plus adaptée, il faut la revoir. On recommence depuis le début, mais avec beaucoup d'expérience en plus. L'expression « on recommence » vous fait peur ? Gardez ceci à l'esprit : le chemin déjà fait ne sera plus à faire. Donc ce n'est pas un redémarrage complet.

Inutile ? Une fois ces acquis solidifiés, non seulement vous avez mis de la valeur dans votre travail, mais vous vous êtes valorisé. Dans tous les points que je cite, il y a un dénominateur commun : la connaissance.

Impossible ? Une anecdote qui vaut ce qu'elle vaut : il y a 2 ans, je commençais à m'intéresser au domaine de la performance Web. Je n'y connaissais pas grand chose. Avoir une note au-dessus de 90 à PageSpeed me semblait être de la science-fiction, tout comme avoir un 1st view à moins de 3 secondes. Maintenant, j'y arrive avec ma méthode de travail standard sur la plupart de mes projets.

Et surtout, une fois que cette base est haute… mais qu'est-ce qu'on se fait plaisir ! :)