Introduction· Déterminer· Analyser· Organiser· Améliorer· Réviser· Maintenir·
QA Accueil· Dernières nouvelles· QA Ressources· QA IG· QA WG· QA Calendrier·
Cet article a été produit dans le cadre du travail du Groupe d'Intérêts sur l'Assurance Qualité du W3C. Veuillez faire parvenir tous commentaires publics à son sujet sur la liste de diffusion publiquement archivée de public-evangelist@w3.org. Pour tous commentaires privés, veuillez contacter directement avec l'auteur, Karl Dubost karl@w3.org.
L'auteur reconnaît l'effort de ceux qui ont consacré du temps à la relecture de ce document et l'ont commenté.
La version française de ce document est une traduction du document original en anglais, réalisée par Denis Boudreau et relue par David Tremblay et Jean-Jacques Solari.
Que vous occupiez un rôle de gestionnaire, de développeur Web, de membre d'une équipe de commercialisation ou de communication ou peut-être de webmestre individuel, vous avez appris l'intérêt des standards Web. Vous avez compris que le respect des standards était bénéfique pour votre site en terme d'économie de coûts, de facilité de gestion et de profitabilité. Ce faisant, vous avez décidé de faire la transition et d'appliquer les normes au profit de votre projet de site Web.
Malheureusement, malgré vos recherches, vous n'êtes pas parvenu à dénicher un guide décrivant la marche à suivre pour vous permettre d'organiser adéquatement cette transition vers une conformité aux standards. Vous êtes peut-être de ceux qui croient à tort que posséder un énorme site Web rend l'objectif inaccessible. Si vous n'êtes pas sûr de la véritable signification [WEB-QUALITY] des standards Web, nous vous encourageons à mieux vous documenter, en particulier comment acheter et développer un site Web de qualité [REQ-WEBAGENCY] et en quoi il est avantageux de posséder un site Web accessible [WAI-PROFIT].
La méthode que nous proposons dans ce document est valable pour des sites Web de toutes tailles. Elle correspondra parfaitement à vos besoins, peu importe que vous dirigiez un site personnel, un site représentant une petite ou moyenne entreprise ou encore, une corporation d'ampleur internationale.
Nous vous guiderons à travers les différentes étapes (que vous pourrez toutes réaliser vous-mêmes) de la transition, allant de l'analyse préliminaire de votre site actuel jusqu'à la restructuration de votre nouveau site Web. Chacune de ces étapes a été développée de manière distincte afin de permettre son implémentation à différentes étapes, différents niveaux et par autant d'individus que vous le jugerez nécessaire, sans égard à leur niveau de compétence, mais conformément à un flux de travaux spécifique.
Peu importe sa taille, votre site Web doit initialement être évalué par rapport aux standards. Vous retrouverez très certainement un bon nombre de pages qui ne satisferont pas aux exigences que vous vous êtes fixées pour la qualité de votre site.
Rassemblez vos équipes de communication, vos équipes techniques, de commercialisation et de gestion afin de dresser la liste de tous les points que vous souhaiteriez évaluer sur votre site Web. A ce stade, il est inutile de ranger par ordre de priorité ce qui doit être amélioré, mais nous vous encourageons fortement à vérifier la validité du code (HTML et CSS), l'accessibilité des documents, et le degré d'internationalisation du site. Vous trouverez des informations sur ces techniques un peu plus loin dans l'article.
Cet article présente une méthode visant à améliorer votre site Web en accord avec les standards issus du W3C, mais vous pouvez également user de cette stratégie pour les autres obligations auxquelles votre site doit faire face. Nous vous proposons une liste non-exhaustive :
Il y aura parfois des situations pour lesquelles vous ou votre équipe ne disposerez pas des compétences ou des connaissances nécessaires à la compréhension des enjeux relatifs à votre site Web; dans un tel cas, n'hésitez pas à demander de l'aide. Invitez un spécialiste en accessibilité ou en internationalisation à prendre part à votre équipe. Par exemple, pour les questions concernant le degré d'accessibilité de votre site (comment les gens avec des handicaps accèdent-ils à vos contenus), vous pouvez demander de l'aide à une association locale, telle qu'une association d'aveugles. Ces groupes seront généralement très heureux de vous assister. De plus, si vous faites partie d'une grande organisation, il est très probable que des personnes handicapées en fassent aussi partie. Parlez-en avec votre département des ressources humaines et invitez-les à participer à ce projet.
Maintenant que vous avez identifié les aspects à vérifier, vous devez déterminer quels sont les problèmes actuels sur votre site. Une bonne façon de faire consiste à dresser une liste complète des URI appartenant en propre à votre site. Ce n'est pas difficile à réaliser; il suffit, par exemple, d'avoir recours à un moteur de balayage qui suivra les pages du site et répertoriera le tout dans un fichier texte, à raison d'un URI par ligne.
Il est tout à fait possible que les technologies utilisées sur votre site Web le rendent inaccessible à un moteur de balayage. Cela pourrait constituer un excellent moyen d'identifier le nombre de page de votre site s'avérant inaccessibles au public. À proprement parler, cet exercice vous indiquera quelles pages de votre site ne peuvent être indexées par les moteurs de recherche pour une raison ou pour une autre signifiant par là qu'une partie du trafic vers votre site est bloquée.
Une fois que vous avez fait cette liste, vous pouvez l'utiliser avec le LogValidator [LOG-VALIDATOR], qui est un programme conçu spécifiquement pour vous venir en aide dans vos démarches d'évaluation. Le logValidator prend la liste des URI associés à votre site et les analyse en fonction du module que vous aurez préalablement choisi de charger pour votre période de test (ce sera probablement du ressort de votre équipe technique de le mettre en oeuvre en fonction de votre propre configuration). Pour chaque URI existant, le programme appliquera une série de tests déterminants et vous proposera les résultats correspondants.
Après cette première phase d'analyse, vous disposerez d'un bilan de santé de votre site Web, et vous serez à même d'adopter une stratégie pour l'organisation des travaux à réaliser afin d'assainir les pages fautives. Vous aurez peut-être un nombre exorbitant de pages qui ne seront pas à la hauteur de vos attentes. Par exemple, il est très possible que vos documents ne soient pas conformes aux normes HTML ou XHTML. Mais ne vous inquiétez pas; en fait, ce serait une très bonne nouvelle ! Pourquoi ? Parce que si vous utilisez un système de gabarits ou un système de gestion de contenus pour générer votre site, cela signifie que vous avez très certainement des erreurs dans vos gabarits.
La solution à votre problème est simple; affairez-vous à corriger vos gabarits et refaites une batterie de tests. Vous obtiendrez probablement moins d'erreurs, peut-être même plus aucune. Si vous n'êtes pas le développeur du système de gabarits, demandez à celui ou ceux qui l'ont créé de corriger ces erreurs. À l'avenir, lorsque le temps viendra de revamper votre site, assurez-vous de suivre les recommandations contenues dans le document Acheter des sites conformes aux normes [REQ-WEBAGENCY].
Si vos pages contiennent toujours des erreurs après cette première vague, ne vous en faites pas — la raison d'être de ce guide consiste justement à vous aider à les corriger.
Un avantage additionnel du logValidator est qu'il permet de se faire une idée très concrète de l'état actuel de toutes les pages de votre site Web. Si vous éprouvez le besoin de déplacer une page ou supprimer une section de votre site, vous aurez une bonne idée de la meilleure façon de rediriger vos visiteurs vers ces nouvelles pages en évitant une perte de trafic provenant de liens externes (comme ceux issus de moteurs de recherche ou d'autres sites). Rappellez-vous, les URI sympas ne changent jamais.
Vous disposez maintenant d'une liste de pages qui ne sont pas conformes ou qui souffrent de problèmes ou d'erreurs. Que cette liste soit longue ou courte importe peu car cela n'affectera en rien la méthode proposée ici. Le premier principe à respecter est simple : "Ne réparez rien ! Améliorez et organisez plutôt votre travail."
Il n'est pas nécessaire de tenter de corriger tout votre site Web d'un seul coup, et ce, pour deux raisons majeures :
De plus, évitez de tomber dans le piège de vouloir corriger une catégorie de problèmes à la fois, en laissant les autres problèmes pour une phase ultérieure de correction. Par exemple, si vous souhaitez rendre vos pages à la fois conformes à la norme HTML et accessibles, entreprenez de le faire en même temps. Si vous traitez ces deux aspects l'un après l'autre, vous risquez fortement d'introduire de nouvelles erreurs qui ruineraient les résultats de la première ronde d'améliorations.
Ainsi donc, ne tentez pas de tout corriger d'un seul coup, ou de corriger les erreurs par cycles ; consacrez plutôt vos efforts à améliorer votre processus d'assainissement.
La clé du succès de cette méthode tient dans le fait de rester réaliste au moment de prendre une décision et de s'assurer que ces décisions aboutiront à autant de résultats probants. Si vous souhaitez améliorer la qualité de vos pages, vous devez déterminer le temps nécessaire à l'assainissement complet de tous les problèmes identifiés pour un document. Faites un essai avec un échantillon de pages Web qui comportent des problèmes similaires et déterminez les compétences et les ressources nécessaires à l'intérieur du flux de travaux de votre site Web.
Une fois que vous aurez déterminé le temps nécessaire à la correction de quelques pages, vous serez mieux à même d'évaluer les ressources qui doivent être allouées à la tâche, de même que le nombre de pages que vous pouvez projeter de corriger quotidiennement de manière réaliste.
Nous vous encourageons à apporter des améliorations à votre site sur une base quotidienne, plutôt qu'hebdomadaire ou mensuelle. Il sera plus facile pour la personne dévolue à cette tâche de planifier le temps quotidien nécessaire à ce processus, et globalement, cela prendra moins de temps chaque jour que chaque semaine. C'est beaucoup plus facile et moins accablant de corriger 5 pages par jour que vingt-cinq en une seule journée.
Tenez des réunions sur une base régulière avec l'équipe chargée de cette tâche. Rassemblez leurs opinions, leurs commentaires et leurs expériences. Cela vous sera d'un grand secours lorsque viendra le temps de déterminer si les erreurs sur votre site proviennent de votre gestionnaire de contenu ou de la méthodologie mise en place pour éditer vos pages. Vous serez en mesure d'améliorer votre processus et la qualité de vos outils par la même occasion.
Après quelques temps, fort de l'expérience que vous aurez accumulée dans la mise en oeuvre de cette méthode, vous serez en mesure de poser des jalons. Par exemple, poser que 50% du trafic parvenant à votre site arrive sur les pages qui sont conformes à vos critères de qualité. Lorsque ce premier but est atteint, augmentez le à 60%, et ainsi de suite. Qu'importe ce que vous avez décidé d'évaluer ou d'atteindre, soyez raisonnable et avancez prudemment ; cette méthode demande des progrès et des améliorations continues mais réalistes.
Afin de faire de votre projet un véritable succès, vous devrez vous assurer d'intégrer à cette tâche tous les intervenants pouvant être appelés à participer au processus de publication de contenus. Comprendre les outils et les méthodes mises en place vous permettra d'établir l'origine des problèmes, s'ils proviennent de vos outils de publication, ou du personnel utilisant ces outils. Quand un outil d'édition introduit des erreurs dans vos documents, cela vous permet d'amasser des commentaires afin de pouvoir négocier avec les créateurs de l'outil en question pour qu'ils améliorent leur logiciel. Cela est particulièrement vrai dans un contexte de grande entreprise où vous disposez de plusieurs utilisateurs; c'est une approche beaucoup plus intelligente pour vous assurer que des améliorations vont être apportées.
Publiez les améliorations apportées au site ; si vous ne pouvez les rendre publiques, assurez-vous au moins de les diffuser à l'interne. Cela démontrera concrètement les progrès et encouragera tous les intervenants à continuer en ce sens. Si vous avez réussi à identifier les problèmes existants dans votre système de publication, vous détenez une bonne piste pour continuer l'amélioration globale du site.
Le LogValidator [LOG-VALIDATOR], qui a déjà été mentionné dans cet article, peut vous aider à améliorer votre site en identifiant les portions qui sont fautives. Dans son mode par défaut, cet outil a été conçu pour vérifier progressivement la conformité de vos documents à la norme HTML. Son principe de base est simple et direct ; à partir d'un fichier de journalisation "log", le logValidator compile les résultats pour ordonner les pages demandées le plus souvent dans une journée et prend les n premières pages du tri résultant (où n représente un nombre que vous spécifiez), et les envoie vers le Validateur du W3C. Par la suite, il vous retourne le résultat de cette validation.
Quels en sont les avantages ? De cette manière, vous corrigez les pages les plus souvent consultées en premier lieu et vous évaluez la qualité de votre site Web en ce sens, non pas en terme du nombre absolu de pages.
Le logValidator possède une architecture ouverte et modulaire écrite en Perl et vous pouvez y ajouter de nouveaux modules selon vos propres besoins. Par exemple, vous pourriez développer un correcteur orthographique, ou un module vérifiant que le logo et le pied de page sont correctement intégrés à vos documents. Vous pourriez même développer un module qui vérifie la présence de liens brisés à l'intérieur de votre site. C'est un outil facile d'installation qui fait partie de l'archive CPAN.
L'étendue des possibilités est infinie ; il vous importe donc d'établir des buts réalistes.
Une fois que vous avez adopté l'utilisation du logValidator, il existe plusieurs façons de procéder pour l'analyse des résultats retournés. Par exemple, vous pourriez fort bien mettre en place une liste de diffusion par le biais de laquelle l'équipe d'assurance qualité de votre site recevrait une liste d'URI à surveiller quotidiennement et votre équipe pourrait soit en amender le contenu, soit signaler quand la source du problème provient d'ailleurs.
Ce guide progressif vise à vous aider à maintenir la qualité de votre site Web, mais vous devez tout de même vérifier régulièrement si les problèmes que vous avez identifiés sont récurrents.
De temps à autres (tous les trois mois par exemple), lancez une nouvelle batterie de tests. Cela vous aidera à déterminer si vous êtes effectivement parvenus à faire de véritables progrès quant à la qualité de votre site Web. Cela vous permettra également de confirmer des erreurs potentielles dans vos systèmes de gabarits. Cela vous permettra également d'atteindre les objectifs que vous vous êtes fixés initialement. Si la qualité de votre site Web n'est pas en hausse, c'est qu'il y a quelque chose qui cloche dans votre processus.
Finalement, cela aura pour effet de récompenser l'effort de votre équipe ainsi que tous les intervenants impliqués dans cet effort en leur démontrant les améliorations qui ont été apportées au site. Petit à petit, vous gagnerez une expérience qui sera bénéfique pour toute votre organisation. Parallèlement à la conduite de ce processus d'assainissement, faites une compilation de tout ce qui a été accompli et publiez-la. Cette compilation deviendra rapidement le manuel de référence pour le respect de la qualité de votre site Web.
Souvent, votre compagnie possède un guide de styles interne qui spécifie la grille graphique de votre compagnie à propos des couleurs de l'entreprise et des logos. Ajoutez ces techniques simples à ce guide, cela aidera votre équipe à améliorer le site Web lorsque des erreurs seront détectées.
La méthode décrite dans ce guide est dynamique et par le fait même, n'est pas coulée dans le béton. Elle doit évoluer avec vos besoins, vos objectifs. Si votre processus de publication requiert des étapes qui ne sont plus pertinentes, si de nouvelles exigences doivent être ajoutées à celles déjà existantes, alors il vous faudra ajuster votre processus de publication et, de ce fait, votre processus d'assurance qualité.
La solution, qui est proposée ici afin d'évaluer et d'améliorer la qualité de votre site, se divise en plusieurs parties interdépendantes. De ce fait, il est possible d'en retirer les portions inutiles, tout comme d'en ajouter de nouvelles si vos besoins allaient en ce sens.
Vous pourriez vous trouver dans une situation où le problème qui vous occupe ne peut être résolu immédiatement en interne par votre équipe pour une raison ou pour une autre. Par exemple, vous utilisez peut-être un outil de publication incapable de produire du code conforme aux normes. Après avoir essayé plusieurs méthodes, plusieurs solutions de rechanges, rien n'y fait. Il devient alors absolument nécessaire de collecter ces informations et de la transmettre à la compagnie ayant conçu le produit, non à titre personnel, mais bien à titre d'entreprise. Vous représentez un segment significatif du marché, de sorte que le fabricant de votre outil favori sera enclin à vous écouter.
Pour maintenir la qualité de votre site Web, vous devrez récompenser les auteurs efficaces et donner un coup de pouce à ceux qui éprouvent des difficultés. Vous ne parviendrez pas à faire de votre projet un succès si vos utilisateurs ne sont pas en mesure de saisir les avantages de la méthode que vous avez instaurée. Invitez et encouragez-les à signaler tout problème dans le processus, avec les outils, etc. C'est toute votre organisation qui s'en trouvera améliorée.
Cette méthode simple est en application depuis des années au sein du W3C pour la gestion des documents HTML. Elle nous a été d'un grand secours afin de maintenir la conformité de toutes nos pages. Lorsque intégrée à la pratique de votre entreprise ou de votre équipe, cette méthode peut s'avérer un outil des plus efficaces.
Nos remerciement vont à tous ceux qui ont accepté de relire cet article : Olivier Théreaux, Stephanie Troeth, Denis Boudreau et la communauté de développeurs sur la liste de diffusion de public-evangelist.
Date de création: 2003-03-28 par Karl Dubost >karl@w3.org>