La qualité : audit lourd versus apprentissage continu (le 5 février 2012)

De nombreux intervenants ou expert ès qualité/accessibilité déconseillent de plus en plus l'audit lourd (également appelé l'audit canonique) qui est donc effectué à la fin du projet, avec une pléthore de points à vérifier, etc. pour une approche différente : celle d'inclure la démarche qualité ou d'accessibilité au fur et à mesure du projet, l'approche dite agile. On parle d'amélioration continue et non plus de respect strict (et bête) de niveaux.

Sur le papier, c'est du bon sens, néanmoins, les (mauvaises) habitudes et les (mauvais) réflexes ayant la vie dure, je vous propose de prendre un exemple concret afin de mieux comprendre en quoi cette approche canonique peut avoir des côtés désagréables. Une précision importante : je ne fais pas les choses par mode, buzz ou dogme, bien que passionné, je suis quelqu'un d'extrêmement froid, fainéant et pragmatique.

Et plutôt qu'un long discours théorique, prenons un retour d'expérience concret : j'ai testé les deux approches… sur ce site.

Évidemment, il faut replacer ça dans son contexte, mais j'y reviendrai.

J'ai commencé à parler de démarches qualité pour ce site en 2004, comme vous pourrez le voir dans les commentaires, Élie Sloim en était d'ailleurs ravi.

Si je résume vulgairement l'approche dite de l'audit lourd, c'est "on vérifie tout après avoir conçu le site". J'étais dans ce cas, j'avais lancé la base de ce site environ 2 mois plus tôt. Donc je me suis amusé à vérifier les 197 bonnes pratiques de l'époque. Honnêtement, c'était surtout un jeu et une bonne technique d'apprentissage à temps perdu de la qualité web.

Cette méthode d'apprentissage a certains avantages, le principal est d'avoir des objectifs relativement clairs et déterminés : il y a une liste, il faut la respecter ! Néanmoins, replaçons cela dans le cadre de l'époque :

la base de mon code était valide et plutôt propre, conforme aux standards, ce qui me validait de facto de nombreux points,
en concepteur du site et de tous ses aspects, j'avais la maîtrise totale et absolue de chacun de ses engrenages et autres rouages,
le site étant relativement jeune, je n'avais pas de gros volumes de données (news, liens, etc.) à gérer,
je n'avais pas de contrainte de temps ni de délai, c'était pour mon site personnel,
le cadre du jeu était l'apprentissage de la qualité, donc hors de tout stress si j'ose dire ! Apprendre est un plaisir.

Cette expérience était très satisfaisante, j'ai appris plein de trucs, j'ai amélioré mon site, j'ai intégré des concepts. Néanmoins, même avec ce plaisir d'apprendre et d'intégrer la qualité, je reconnais que certains points ont été extrêmement frustrants à corriger, et il m'a fallu beaucoup, beaucoup de temps pour les résoudre : je pense notamment à la différenciation des liens internes et externes, je crois ne l'avoir intégrée qu'assez récemment dans mes derniers skins.

Qui plus est, la liste des bonnes pratiques s'étoffant, certains nouveaux points deviennent compliqués à ajouter, même à temps perdu, vous imaginez le boulot si je dois reprendre 1600 news une à une ?

Maintenant, sortons de l'idyllique cadre d'apprentissage à temps perdu, et revenons à la dure réalité ! En pratique, vous connaissez beaucoup de sites :

avec un code particulièrement pur,
dont vous avez la maîtrise totale et absolue,
sans gros volume de base de données à traiter ou à reprendre,
et sans contrainte de temps ou de délai à gérer ?

Si oui, ne changez pas de job, vous avez les cas les plus faciles, c'est parfait ! :)
Honnêtement, je crois n'avoir rencontré ces cas plaisants que très rarement. En pratique sur de grosses refontes, c'est quasiment impossible. Prenez le contrario des points énumérés ci-dessus, et selon moi vous aurez même une bonne méthode d'évaluation de la difficulté d'un projet, je parle d'ailleurs souvent de "l'échelle peau de banane" pour qualifier ces projets difficiles.

Imaginez donc : déjà dans le cas idéal, j'ai rencontré certaines grosses frustrations. Imaginez donc dans le cas pas idéal du tout les frustrations que vous pouvez avoir.

Ou alors, j'avais déjà pensé en concevant certains sites à inclure tous ces points afin d'être sûr que ça valide à la fin (vous voyez déjà là des embryons de l'autre méthode : inclure au fur et à mesure la qualité).

Penser en amont les problèmes, les contraintes, les objectifs, etc. je l'ai fait sur la dernière CSS alternative de ce site, par exemple : les performances, l'adaptation aux smartphones, etc. En ayant dans un coin de la tête ce que je vise, je travaille en fonction. C'est évident de l'énoncer ainsi, mais quand vous êtes pris dans l'enfer de l'action sous perfusion de stress avec une liste de 217 critères à respecter, ce n'est pas toujours aussi simple !

Vous avez peut-être constaté une chose : rien que d'appliquer de manière lourde et massive l'approche dite canonique me mène naturellement… à une méthode agile ! (sauf à aimer être masochiste, mais là c'est un autre débat)

La méthode dite agile vous permet de protéger votre santé mentale : imaginez un site de 10 000 pages dont vous devez reprendre chacune des pages en temps limité. Même si vous êtes le meilleur intégrateur du monde, ce n'est pas possible. Faites un deuil. Par contre, travailler à l'amélioration avec des gains faciles (quick wins en anglais), c'est beaucoup plus simple à gérer : moins de stress, moins d'échec, etc. et surtout, on reste dans le domaine du possible, avec une bonne dynamique positive.

À mon sens, la méthode lourde n'a de sens que si vous êtes dans un cas d'apprentissage : absorber tous ces bons points vous permettra de les restituer facilement. Le but étant pour vous que cela devienne un réflexe, ainsi votre travail de base, ou plutôt votre base de travail aura déjà un haut niveau de qualité intrinsèque. C'est là le but final de la méthode agile, enfin à mon humble avis.

Sachant que la qualité a une qualité : elle attire la qualité. Ajouter de nouvelles choses sur du travail bien fait, c'est possible, agréable et parfois même facile. J'étais par exemple à mille lieues de penser il y a 8 ans qu'une unique CSS gèrerait l'affichage du site, sa version imprimable et une version petit écran… le tout optimisé pour les performances web.

En bref, vous comprenez maintenant pourquoi je conseille une approche moins stricte, décomplexée et plus agile de l'accessibilité et de la qualité : aucun dogme, mais un simple retour d'expérience. Je suis passé par la méthode brute… je vous la déconseille vivement en milieu professionnel, pour votre santé mentale.

Permalien : https://www.nicolas-hoffmann.net/source/1450-La-qualite-audit-lourd-VS-apprentissage-continu.html

Flux RSS des commentaires de ce billet : https://www.nicolas-hoffmann.net/rss/commentaires.php?id_news=1450

6 commentaires

Posté par Victor Brito le 05/02/2012 à 17:18:53

Un bon résumé applicable également à une démarche d'accessibilité (labellisation contre amélioration progressive et continue).

Posté par Nico le 06/02/2012 à 12:49:41

Merci !

C'est du vécu... depuis quelques années !

Posté par Alf le 06/02/2012 à 19:26:21

Je suis partisan de - et j'utilise - l'amélioration continue, mais force est de constater que quand on a 300 critères qualité à respecter, difficile de ne pas en oublier en route ! Du coup, on passe plus de temps à "penser" l'application qu'à réfléchir au code proprement dit ! Après, c'est sur que s'il y a des modifs à faire une fois l'appli en place, c'est tout de suite plus facile... C'est de vécu pour moi aussi

Un bon (et un mauvais) exemple est mon site perso pour moi aussi : à l'époque j'étais un parfait débutant en développement web, et énormément de choses sont à revoir tant dans sa conception que du code (et je ne parle pas de "l'habillage" !). Tellement que j'aimerais le "refondre" de A à Z. Malheureusement, pas beaucoup de temps pour le faire ! J'étais quand même fier, à sa création, de n'avoir aucune erreur au validateur W3C

Posté par Olivier Nourry le 08/02/2012 à 15:26:33

Nicolas,
En général je suis d’accord avec toi, et ça ne change pas fondamentalement ici. Mais il y a deux choses qui me gênent dans ta formulation des choses, qui à mon avis desservent ton propos par ailleurs tout-à-fait valide. Donc, en toute amitié, voici mon analyse critique.

Tu utilises l’expression « audit lourd », qui à mon avis est ambiguë, en plus d’être connotée (qui aime un truc associé à « lourd », à part les routiers et… euh… à part les routiers ?). Pour moi, ça induit l’idée de quelque chose de très poussé, c’est-à-dire utilisant tout l’arsenal. Pour un même critère, on utiliserait les tests automatiques, les tests d’expert, les tests utilisateurs, les tests par des persona, les alcootests –pour les soirs de livraison – bref, une panoplie complète, pour être sûr de ne rien louper. En ce sens, d’ailleurs, ce serait un audit fin, plutôt que lourd, même si la charge de travail est de fait très lourde, ce qui invalide l’option dans la plupart des situations de projet. Mais pas toutes ! Le processus de paiement sur un site de vente, par exemple, mériterait cette méticulosité. Il me semble que ce tu évoques serait mieux décrit par « complet », c’est-à-dire qu’on exécute tous les tests. Et on peut tout-à-fait faire un audit « complet » qui soit « léger », c’est-à-dire qu’on procède par échantillonnage, en utilisant à chaque fois test le moyen le moins dispendieux. A ce sujet, je t’invite à consulter cet excellent article de Karl Groves : http://www.karlgroves.com/2012/02/02/web-accessibility-testing-do-automatic-testing-first/.

Ensuite, tu mets sur le même plan, implicitement, l’outil et la méthode, en opposant l’audit à l’approche progressive. Or, l’approche progressive n’empêche pas l’audit, qui est un outil parmi d’autres. Quelque soit l’action qualité, elle commence et se vérifie par une mesure, et l’audit est un instrument de grande valeur de ce point de vue. Reste à bien l’utiliser. Les vraies bonnes questions, je pense, sont : quel type d’audit est le plus adapté à ma situation, sur quel périmètre, quelle étendue, comment et quand je le mets en œuvre. J’espère qu’on en n’est plus à expliquer que se demander seulement en fin de projet ce que ça vaut, coté access, c’est aussi idiot que de manger une bourriche d’huîtres et de demander ensuite si elles étaient fraîches. Il y a 2-3 ans, j’avais encore des demandes du type « auditez mon site et dites-moi qu’il est accessible ». Aujourd’hui, ça n’arrive plus, on est plutôt dans la demande de confirmation suite à une opération de correction globale, ou alors pour poser un diagnostic exhaustif de début, pour comprendre où on va devoir travailler. Dans les deux cas, on parle de 2-3 jours de travail pour un audit qui permettrait d’attester la conformité RGAA et/ou Accessiweb, ça ne me paraît pas de l’ordre du « lourd », bien que ce soit complet. D’ailleurs, sur des opérations d’accompagnement pour refonte (voir par exemple pour le site JeunesOCentre : http://www.slideshare.net/Shemzone/joc-v3comments ), je pratique ainsi :
1. audit exhaustif sur un échantillon représentatif
2. identification des axes de travail avec la MOE, pour définir des charges
3. arbitrage (si possible)
4. support au développement, en continu : répondre aux questions, fournir des notes techniques spécialisées en fonction du projet
5. tests intermédiaires pour les sujets « touchy »
6. audit de fin, pour confirmer qu’on a bien travaillé
Le tout tient en 8-10 jours pour un projet moyen, dont la moitié en audits…

Donc, je ne pense qu’il faille jeter l’audit avec l’eau de la méthode utilisée. L’audit est une lame, très polyvalente et très robuste, donc majeure, sur le couteau suisse de la qualité (et là je marque des points au challenge Notabene des métaphores à la con).

Posté par Nico le 08/02/2012 à 17:45:54

Pas de souci, je suis ouvert à toute critique argumentée... c'est le cas de la tienne.

Autant pour moi, j'utilise effectivement cette expression ambigüe d'audit lourd car c'est ainsi que je l'ai pratiquée et ressentie (et pour l'avoir entendu lors d'une conférence à Paris-web, il colle bien avec la sensation que j'ai eu) : "je regarde après de manière exhaustive ce que j'ai fait SANS avoir eu cette connaissance AVANT".

C'est un ressenti totalement personnel.

Et là, patatrac ! C'est pour cela que je parle bien de lourdeur, car en général on se prend quelques enclumes sur la tête (moi aussi je concours pour la métaphore la plus débile de Notabene).

Ça n'invalide pas le fait que ce dernier soit nécessaire dans certains cas et ça ne le rend pas incompatible avec l'approche agile, on est bien d'accord.

Reste qu'utiliser cet audit ainsi est mortel pour la motivation. Par contre, l'utiliser en checklist à la suite de méthodes agiles où l'on a accompagné une équipe, ça ne gêne pas, au contraire : c'est une validation et un gage de succès.

Le seul point que je vois et que tu as souligné d'ailleurs : quel type d'état des lieux est le plus adapté ? Comme tu le dis, j'ai pas besoin de 250 critères de qualité venant d'un expert en huîtres... si le plus primordial, la fraîcheur, n'est pas respecté. Là l'expert ès huîtres doit orienter !

Au plaisir d'échanger avec toi ! (toujours un très grand plaisir d'ailleurs)

Posté par Olivier Nourry le 08/02/2012 à 17:50:56

Nico a écrit: "j'ai pas besoin de 250 critères de qualité venant d'un expert en huîtres... si le plus primordial, la fraîcheur, n'est pas respecté".
Voila, pile poil (décidément ces huîtres ont un fort potentiel métaphorique). La valeur (j'ai failli taper "l'avaleur") ajoutée de l'expert est précisément de prioriser correctement, et en second lieu, de donner les bons outils pour la bonne tâche.
Non, mais en fait, pas du tout, contrairement à ce qu'on a dit, on est d'accord :o)

La qualité : audit lourd versus apprentissage continu

La qualité : audit lourd versus apprentissage continu (le 5 février 2012)

6 commentaires

Ajouter un commentaire