Auteur(s) : Elie Sloïm
Publié le : 2-7-2003
Résumé : Au delà du cas individuel que représente la conformité aux standards du Web du site temesis.com, pourquoi et comment communiquer sur l'intérêt de la conformité ? Au moment de pérenniser les activités en ligne, il devient essentiel de prévoir tout ce qui contribue à leur qualité.
Les dernières nouvelles de la société, notre analyse de certains événements ou articles sur la qualité, la conformité ou l'accessibilité :
1. Tout est beau ?
2. Pourquoi pas eux ?
3. Pourquoi pas eux 2 - le retour ;-)
4. Un préalable souhaitable, mais pas obligatoire
5. Communiquer autrement ?
6. Communiquer sur les coûts et les limites
7. Vers un autre niveau de conformité
Voilà, nous sommes conformes, nous nous dirigeons tout droit vers la conformité XHTML 1.0 STRICT. Notre site est accessible, et tout va pour le mieux dans le meilleur des mondes ? Non, pas du tout, en tous cas pas du point de vue de la qualité d'Internet.
Les personnes qui assurent la promotion des standards du Web ont raison, et ils ont un rôle essentiel à jouer dans ce développement : il reste beaucoup de travail à faire pour sensibiliser à la nécessité d'utiliser et de se mettre en conformité avec les standards du Web.
De nombreux freins existent au développement de ces standards et nous essayerons d'en comprendre les raisons. Nous verrons aussi que pour convaincre et évangéliser à grande échelle les webmasters, il faudra certainement tenir compte du fait que comme beaucoup d'autres approches techniques, l'approche conformité ne vaut que lorsqu'elle est durablement mise dans une perspective plus large.
Je vais donc me faire l'avocat du diable, tout en sachant que mon objectif est de donner un modeste coup de main à cette démarche en proposant un autre point de vue délibérément critique et dissonant.
Pour m'amuser un peu, j'ai testé la page d'accueil d'une vingtaine de sites Internet de portée nationale ou internationale, moteurs de recherche ou annuaires de renommée mondiale, sites de e-commerce et d'information américains et Français.
Mauvaise nouvelle : aucun des sites testés ne passe au validateur du W3C, c'est à dire que je n'ai jamais vu ce message : "this page is valid NORME"
Le nombre d'erreurs est rarement affiché puisque l'outil de validation ne peut effectuer l'analyse. Dans certains cas, comme google.com (le 27 mai à 13 heures), la réponse est "Fatal Error : No DOCTYPE specified !"
Faut-il en déduire que Google est un site de mauvaise qualité ? Ce serait bien évidemment une énormité.
Cette constatation matérialise très nettement la différence existant entre "conformité et qualité informatique", et "qualité perçue par les internautes".
Pour évangéliser sur les standards du Web, cette situation ne facilite certainement pas la communication par l'exemple.
En conséquence, si nous ne voulons pas que ces contre-exemples ne servent à justifier une position d'attente par rapport à ce problème, et cette fois-ci, je parle en tant que webmaster non informaticien, nous avons un besoin urgent de comprendre les raisons qui poussent ces sites à ne pas se mettre en conformité.
C'est à cette seule condition que nous pourrons savoir si ces raisons sont valables ou pas. Personnellement, j'ignore bien évidemment ces raisons mais je vais me risquer à évoquer quelques raisons possibles :
Dans tous les cas, c'est une très mauvaise nouvelle pour le développement des standards du Web.
Pour espérer sensibiliser les webmasters de sites à la conformité aux standards du web, nous devons leur expliquer pourquoi une bonne partie de leur environnement, pousse très exactement en sens inverse.
Ainsi, de nombreux outils de conception de pages, certains navigateurs proposés par les même entreprises qui prônent l'utilisation de standards du web, les technologies, les prestataires, contribuent tous à la production de sites non conformes.
Il y a fort à parier que le nombre de sites conformes augmenteraient en flèche si les prestataires, les technologies, les navigateurs, et les outils de production étaient eux même compatibles avec les standards du web.
Ce n'est pas le cas, et c'est normal. Il est des périodes où les avantages liés au foisonnement technologique sont supérieurs à ceux générés par la stabilisation et la normalisation des techniques.
C'est typiquement le cas de la période d'innovation débridée que nous venons de connaître, mais il est peut-être temps de faire la part belle à la pérennisation, non pas pour brider l'innovation, mais au contraire pour lui permettre de s'épanouir sur des bases fiables et reconnues de tous.
Autrement dit, le temps est venu d'évangéliser sur les standards, et ceux qui s'y sont attelés ne se trompent pas. Mais espérons qu'ils ne se trompent ni de public, ni de méthodes.
Les problèmes de conformité ne sont pas nouveaux. La qualité informatique non plus. La gestion de projet, les méthodes et normes de conception et de certification de la qualité logicielle en font partie, et ces sujets sont traités et appliqués à grande échelle depuis longtemps dans les directions informatiques.
Mais lorsque j'entends dire qu'il suffirait que ces outils et méthodes de la qualité informatique soient mis en application par tous les créateurs de services en ligne pour que la qualité de ces services soient au rendez-vous, je m'inscris en faux.
Cette dernière affirmation me semble en effet hasardeuse. Pour s'en convaincre, il suffit de citer deux cas fréquents :
C'est l'une des raisons pour laquelle la mise en conformité aux standards doit être présentée non pas comme un signe de qualité obligatoire mais comme un outil d'amélioration de la qualité des sites comme il en existe d'autres, et au même titre que les autres.
De la même façon, en posant la conformité aux standards du Web à la fois comme un préalable souhaitable, une assurance nécessaire (voir article 3), et pourquoi pas un outil de l'e-qualité, on ne ment pas sur la marchandise, ce qui rendra d'autant plus facile de convaincre ceux qui prennent des décisions.
Internet a démocratisé la création de services en ligne : de la même façon que l'ergonomie n'est plus seulement une affaire d'ergonomes, mais aussi un sujet devant préoccuper tout auteur de site personnel ou professionnel, la qualité informatique n'est plus seulement une affaire d'informaticiens.
La conformité concerne des publics non-spécialistess et non-membres de communautés d'intérêt.
C'est pourquoi une communication pédagogique, communautaire, par l'intermédiaire de sites qui montrent l'exemple est une excellente méthode. C'est d'ailleurs l'optique retenue sur le site OpenWeb, excellente mais rarissime initiative dans ce domaine.
Les autres modes de communication autour des standards sont soit des blogs, outils d'expression personnels, qui personnalisent à outrance une démarche qui est collective par nature, soit des sites présupposant une excellente connaissance technique du domaine.
Dans les deux cas, ces outils de communication peuvent souvent s'avérer des machines à exclure certains publics d'un sujet qui les concerne pourtant au premier chef.
Autrement dit, pour évangéliser des décideurs, par exemple, qui prendront ou non la décision d'investir du temps et de l'argent dans une mise en conformité, il faudra parler leur langage et leur fournir des pistes et des outils faciles d'accès pour commencer.
La mise en oeuvre d'un site Internet nécessite de prendre des décisions. Ces décisions doivent être prises en connaissance de cause, et en l'occurrence, il est non seulement absolument essentiel de savoir ce qu'une mise en conformité va vous apporter, mais aussi ce qu'elle ne pourra pas vous apporter.
C'est pourquoi je crois nécessaire et utile de mettre évidence les limites des méthodes d'amélioration de l'e-qualité. Non la mise en conformité ne résoudra pas tous vos problèmes d'ergonomie. Non, elle ne vous permettra pas d'améliorer vos réponses aux e-mails. Mais en revanche, elle vous permettra peut-être de dégager du temps que vous rentabiliserez par ailleurs (à travers la réutilisabilité du code ou l'optimisation du temps consacré à la programmation, par exemple). Cela pose d'ailleurs directement la question du retour sur investissement de la mise en conformité, auquel je ne sais pas encore répondre de manière claire.
Pour finir, il est absolument nécessaire pour les décideurs de pouvoir évaluer le temps et les ressources nécessaires (formation, notamment) pour se mettre en conformité. A l'heure ou je vous parle, j'ignore par exemple totalement combien de temps, combien nous coûtera et combien nous rapportera la mise en conformité XHTML 1.0 STRICT
Ce choix d'aller vers XHTML STRICT ne vient pas d'une véritable analyse de ma part, mais d'un échange avec Tristan Nitot, qui m'a précédemment indiqué que c'était la voie à suivre pour différentes raisons, et notamment la séparation de la structure et du contenu.
C'est un argument auquel je suis sensible, puisque c'est la voie que j'ai choisie en 2001 lorsque j'ai proposé le modèle VPTCS (visibilité perception, technique contenu services), qui sépare totalement la qualité intrinsèque du contenu (C) de la qualité de la façon dont il est présenté (P) et des aspects techniques de son acheminement et de son fonctionnement (T).
Si la suite de cette démarche de mise en conformité est intéressante, nous vous tiendrons au courant. Je suis intimement persuadé que la mise en conformité XHTML 1. STRICT va nous demander un travail et une remise en cause beaucoup plus profonde que je ne peux l'imaginer pour l'instant.
Ces éléments me sont encore inconnus, mais qui sait, j'aurai peut-être alors en ma possession les conséquences et implications non techniques, dont j'aurais théoriquement eu besoin pour décider en connaissance de cause.
A suivre.
Partie 4.
