<C²: webløg />

Courriel - email address

Avatar Denis

vendredi 16 avril 2004
par Denis Boudreau

Remettre les pendules de l'accessibilité à l'heure

Après une dizaine de jours de mutisme plus ou moins volontaire, de restructuration de nucléus familial et de grève solidaire (pas mal pour si peu de temps), je suis de retour à l'alimentation de ce carnet, avec des piles fraîches, de nouvelles idées et un nouveau regard sur mes préoccupation d'artisan Web.

Le recul des derniers jours m'a été extrêmement bénéfique, tant au plan personnel que professionnel. Alors que les carnets Web de certains copains semblent vouloir tomber les uns après les autres, je me rends compte avec plaisir que j'ai toujours envie de poursuivre l'aventure, que la feu sacré brûle toujours... voilà bien la première chose dont je devais m'assurer avant de reprendre le flambeau pour plusieurs mois encore. Le printemps et l'été s'annoncent chauds ! Reprenons donc sans plus tarder :

Attention, les opinions exprimées dans ce message risquent d'en déranger plus d'un, mais n'ont aucun autre but que de briser les mythes et de remettre les pendules à l'heure. Ce commentaire et les réflexions qui en découlent ont été tirées et adaptées d'une de mes interventions sur le forum Webmaster-Hub, dans le cadre d'une discussion sur l'accessibilité.

Moins cher, de bien faire ?

Lorsque l'on parle d'accessibilité ou de mise en conformité, tout le monde s'accorde pour dire qu'un site bien construit ne devrait pas être plus coûteux qu'un site construit n'importe comment. Mieux encore, bon nombre vont même aller jusqu'à dire que construire un site selon les normes, ça coûte moins cher et ça se réalise plus rapidement qu'un site bâti selon les techniques du millénaire passé.

Je vous l'accorde, c'est ce que tout le monde dit et répète inlassablement, c'est le discours tenu par les évangélistes dont je fais partie, c'est également le discours tenu par tous les OpenWeb et tous les wannabe Zeldman de ce monde. Bref, c'est le discours universel de tout ce beau monde, un discours à consonnance fausse et trompeuse, qui risque un jour de nous rattrapper et de causer notre perte. Ce que ce que je constate, c'est qu'au final, tout le monde ne fait que répéter les mêmes vieux trucs dans ses propres mots et personne ne semble réfléchir deux secondes aux impacts réels de ce discours dans l'industrie...

Et ça, à mon avis, il faut que ça cesse. En vérité, ce n'est pas tout à fait vrai que bien faire coûte moins cher et il est grand temps que l'on commence à adresser les problématiques dans un ordre et une perspective réelle et concrète.

Car continuer à diffuser cette idée trompeuse, c'est à nouveau embarquer dans un cycle de mensonge face aux décideurs qui seront éventuellement vendus à l'idée. La dernière chose que nous voulons, c'est d'arriver à un point où ces mêmes décideurs associeraient naturellement le mouvement de standardisation à tous les autres mensonges et promesses éhontées des dernières années, aux buzzwords et au vaporware qui ont largement contribué à faire éclater la bulle technologique, à réduire à néant la confiance des décideurs envers l'industrie du multimédia au tournant du siècle.

Je suis passé par là, vous êtes peut-être passés par là aussi. Personnellement, je ne tiens pas à y retourner du tout. Je souhaite construire avec eux une relation saine, un relation de confiance basée sur le partage et la diffusion des connaissances, de la vérité. Pour ce faire, il faut revoir certains de nos arguments en faveur des normes et avoir le courage de les nuancer.

Remettre les choses en contexte

Si pour un développeur expérimenté il est effectivement plus rapide de bien faire (tout conforme, standard et accessible), que de se forcer à faire selon les vieilles techniques du millénaire dernier, il en va tout autrement pour un développeur qui ne serait pas, ou alors très peu expérimenté avec les méthodologies de développement standardisées et accessibles disponibles aujourd'hui.

Pour ceux-ci, arriver à bien coder un site selon les règles de l'art demande un effort majeur et une adaptation considérable qui a inévitablement un prix, souvent très fort dans le déploiement d'un projet... Il faut le reconnaître une fois pour toutes et ne plus avoir peur des mots ; faire conforme et accessible, ça coûte plus cher, ne serait-ce qu'en courbe d'apprentissage et en exploration par essais et erreurs avant de bien maîtriserles technologies et leurs subtilités variables dans les différents agents utilisateurs.

Par la suite, une fois que les techniques et les technologies seront maîtrisées, oui il en coûtera beaucoup moins cher pour déveloper un projet, mais combien de temps l'agence devra t-elle soutenir son équipe avant d'atteindre ce degré d'expertise pour en bénéficier ? Le vrai argument (et c'est celui sur lequel il faudrait je crois insister), c'est que malgré le coût supérieur, l'effort d'amélioration et les remises en cause, l'investissement en vaut pleinement la peine pour toutes les autres raisons que l'on a maintes et maintes fois répétées.

Les plus audacieux, dont le designer Andy Budd, avancent que faire un site accessible a un coût associé d'environ 2% supplémentaire... c'est un pourcentage raisonnable pour un développeur expérimenté qui sait exactement ce qu'il fait et ce qui doit être systématiquement mis en place pour réussir à la tâche. Pour celui qui ne connait pas le W3C, faire accessible et conforme représente beaucoup plus que 2%. C'est probablement beaucoup plus de l'ordre du 75% à 100%, surtout s'il se lance aveuglément dans le l'abandon des tableaux HTML et la poursuite du sacro-saint triple A de la WAI.

Celui qui fait la navette entre le WCAG et son site, qui tente désespérément de comprendre les messages cryptiques des validateurs, de trancher entre ses vieilles habitudes et des pratiques recommandables qu'il ne maîtrise pas encore et qui recherche encore la perfection au pixel près entre Mozilla 1.6 et Netscape 4 ne pourra jamais faire un site conforme et accessible au même coût qu'un site fait selon ses vieilles habitudes.

Par vieilles habitude, et c'est là que le bât blesse, j'entends n'importe comment, sans réfléchir le moindrement à la portée du moindre octet de HTML lâché dans ses pages.

Donc je résume simplement en disant que c'est faux d'affirmer systématiquement que le développement conforme et accessible coûte moins cher... Il faut commencer à nuancer nos propos en admettant qu'il y a véritablement un coût associé à la mise à niveau des méthodologies de développement, que l'effort pour gravir la courbe d'apprentissage n'est pas forcément simple pour tout le monde, mais que nonobstant ces faits, le jeu en vaut largement la chandelle

Être visionnaire, c'est comprendre qu'il faut voir à long terme et investir dans ses ressources pour les aider à se dépasser et à produire des projets sans cesse supérieurs en terme de qualité et d'innovations. Et que les efforts associés à cette mise à niveau méritent pleinement de valider l'intérêt de cracher les dollars supplémentaires pour bien faire le travail.

Denis Boudreau | 2004.04.16 @ 23:52

Alors, qu'en pensez-vous ?

Voici ce que vous aviez à en dire... vos impressions, recueillies à vif.

2004.04.17 @ 06:11 par Laurent Denis

Hum... Là, je ne te suis plus.

Comme je te l'avais répondu sur le forum Webmaster-Hub, il manque une donnée essentielle à cette analyse : la méthode de passage aux standards et à l'accessibilité.

Standardisation et 'accessibilisation' ne sont pas une question de 'tout ou rien'. Ce sont des démarches progressives, définissant des priorités, aboutissant à de choix en fonction des besoins, des coûts, des moyens et notamment côté formation.

C'est également une question de planification à long terme.

Bref, il s'agit d'inviter à raisonner en terme d'investissement et de profit, et surtout d'expliquer comment définir des stratégies rentables, plutôt que d'effrayer en brandissant des coûts.

Haut retour au début de la page

2004.04.17 @ 06:40 par Sylvain Lelièvre

Il est vrai que passer aux standards après avoir pratiqué pendant des années les méthodes ancestrales, cela demande du temps, des efforts, et bien sûr de l'argent si cela s'inscrit dans le cadre professionnel.
Mais je ne pense pas que les évangélisateurs ignorent ce fait, et cela parce qu'on est tous passés par ce stade de remise en question de nos habitudes et d'apprentissage de nouvelles méthodes, transition qui ne s'est pas faite en un clin d'oeil.
Mais certainement qu'une fois cette étape franchie, on est tellement enthousiasmé par les nouvelles possibilités que nous offre les standards et l'accessibilité, qu'on en oublie la période de transition (plus ou moins fastidieuse selon les cas) par laquelle on est passé, et qu'on 'oublie' (plus ou moins volontairement) d'aviser ceux qu'on essaie d'initier.

Mais en même temps, cela montre le besoin d'une méthode éprouvée et reconnue que les entreprises pourraient appliquer pour passer aux standards en toute quiétude, pour éviter les pièges traditionnels dans lesquels tombent ceux qui s'essaient à ces nouvelles méthodes. Etant donné que les méthodes de conception prenant en comptent les standards et l'accessibilité sont de plus en plus considérées par les entreprises, il y a certainement un filon à creuser, notamment dans les domaines du consulting et de la formation.

Haut retour au début de la page

2004.04.17 @ 06:42 par Normand Lamoureux

Coûts de production et coûts de formation sont effectivement à distinguer. Et c'est justement pour ne pas l'avoir été assez jusqu'à maintenant que l'argumentation de Denis prend toute son importance.

En soi, produire un site conforme et accessible n'est pas forcément plus cher. Mais dans les faits, tout dépend de celui qui a à se taper le boulot. Car si le développeur n'y comprend rien aux normes et tente de s'y mettre par la même occasion, on ne parle plus seulement de coûts de production, mais de coûts de formation surajoutés.

Ce qui montre que la courbe d'apprentissage doit être prise en considération d'une manière plus sérieuse qu'elle ne l'a été jusqu'à présent... et qu'il est grand temps que W3Québec se mette à offrir des sessions de perfectionnement aux développeurs.

Alors, Denis, on commence quand ? Cet été ?

Haut retour au début de la page

2004.04.17 @ 07:53 par Denis

Laurent, je ne vois pas pourquoi tu ne me suivrais plus dans mon raisonnement, je dis toujours la même chose... seulement, tu devances ma réflexion en pensant déjà aux solutions alors que j'en suis toujours qu'à démontrer le problème et ses portées. ;)

Tout n'est pas qu'une question de noir ou de blanc c'est certain, la démarche est effectivement progressive et le pourcentage supplémentaire en terme d'effort sera toujours inversement proportionnel à l'expérience et à la compétence du développeur qui entreprend le projet. Comme je prenais deux exemples diam.étralement opposé (à savoir, un expert XHTML/CSS et un expert des hacks qui ne connait pas le W3C), mon argumentaire se tient. Maintenant, plus notre hacker de service s'ouvrira à la réalité de son industrie et plus il se responsabilisera vis-à-vis sa pratique, plus il sera en mesure de produire mieux, en moins de temps, avec de meilleurs résultats.

Sylvain, je suis d'accord avec toi que les évangélistes n'ignorent en rien ce fait. Je le sais moi-même pour être passé par là, pareil comme toi et tous les autres. Quelque part dans le fond de nos têtes, nous savons très bien que l'argument est à moitié vrai... Mais c'est justement de le présenter comme une demi-vérité qui doit cesser, parce que dans l'esprit du décideur qui fait reposer sa confiance en nous, la prise de conscience de cette réalité sera doublement cuisante lorsque son budget qu'il espérait récupérer en partie se mettra à fondre comme neige au soleil.

Normand, je n'en attendais pas moins de toi, fidèle compagnon ! Sans le savoir, notre réflexion est déjà amorcée avec cet article dont nous parlons depuis un moment. ;)

À ton commentaire, je rajouterai simplement qu'il nous faut non seulement parler de coûts de production et de coûts de formation, mais également de coût d'exploitation supplémentaire et de contingence... qui seront appelés à disparaître avec le temps, pour ne laisser au final que de la rentabilité et de la productivité accrue.

Le mot d'ordre ; penser à long terme, penser à la pérennité et la réutilisabilité des documents produits.

Haut retour au début de la page

2004.04.17 @ 13:47 par Benoit Piette

La comparaison que je donne pour représenter la complexité du passage du non conforme au conforme W3C (avec la philosophie qui s'y ratache) est la suivante :

Le passage au standard W3C est aux interfaces Web ce que le passage du procédural à l'orienté objet a été aux systèmes d'entreprise. Les avantages sont sensiblement les mêmes (réutilisation, coût moindre de maintenance, etc.) et les dangers aussi (peut être complexe pour les non initiés), dans une moindre mesure. (Passer aux standards W3C est quand même je crois moins difficile que le passage à l'orienté objet.)

Les décideurs se souviennent des projets de passage à l'orienté objet et savent que parfois cela peut être difficile, mais qu'en bout de compte, à moyen terme, c'est très avantageux. Aujourd'hui presque toutes les grandes entreprises font de l'orienté objet, et on ne se pose plus la question. La même chose va se passer pour le Web à mon avis.








Haut retour au début de la page

2004.04.17 @ 15:03 par Bleizig

Je ne suis pas d'accord avec ton raisonnement Denis.
Un site conforme coûte mois cher qu'un site qui ne l'est pas pour des raisons variées que nous connaissons tous (bande passante, maintenance ...)

Maintenent, tout changement, quel qu'il soit, a un coût, mais les décideurs en entreprise ont besoin de ne savoir qu'une chose: le retour sur investissement. Et dans ce cas, quand il s'agit de faire l'addition, les sites conformes ont le dessus.

Si tout le monde, effrayé à l'idée de devoir débourser un peu, refusait le changement, nous n'irions pas très loin. Je pense que c'est la dessus qu'il faut argumenter au lieu de se limiter a une vision à très court terme.

Haut retour au début de la page

2004.04.17 @ 15:32 par Damien Hardy [Dam_ned]

J'aimerais ajouter que ce qui coute le plus cher quand un designer web passe du 'quirk' aux standards c'est surtout les innévitables hacks pour i.e. J'ai pour exemple mon frère (designer web de son état) qui me propose de l'aider à refaire une page avec les standards web. Je mets une structure à base de listes dans les menus, de hx, des fonds pour les header pour coller son design les courbes dans tout les sens, la bare en bas de la fenêtre ... nickel sous Mozilla ... hop il test sous i.e. ... hargggllll !!! le sagoin il respecte rien.
Bref le design fait sous moz en une soirée même pas.. et plusieur jours pour essayer de faire en sorte que ca ressemble à l'attendu sous i.e. (sans que ca soit identique de toute façon) à coup de hack (s'appuyant sur le nom respect des standard de i.e. comme le selecteur > ou !important )

Dam

Haut retour au début de la page

2004.04.18 @ 06:54 par Gloom

'Passer aux standards W3C est quand même je crois moins difficile que le passage à l'orienté objet.'

Effectivement, j'ai essayer de passer à l'orienté objet et, j'ai laissé tombé... Passer au standards du W3C et en partie à l'accessibilité (car j'ai encore du chemin à faire à ce niveau là) est bien plus facile.

Pour ma part, je me dis qu'a mon niveau, il vaut mieux tanter d'ammener les webmasters à se mettre au standard et que ceux-ci entrainerons leurs patrons dans le respect des standart et une cherche de la meilleurs accessibilité sans même que ces derniers s'en rendent compte. Tout dépend de l'entreprise évidament, mais, il y a beaucoup de gens qui emplois des webmasteurs sans avoir idée de ce que c'est que l'html et pour qui internet, c'est quand on clic sur le 'e' bleu sur le bureau de windows. Plus il y aura de webmasteurs qui se mettrons au standart plus ça ira de soi de faire des sites conformes, quelque soit le contexte.

Maintenant, la problématique réside dans le fait que des entreprisent n'ayant pas concience de ce qu'ils font emplois des webmasters qui utilise des méthodes désuette et que, tant qu'il ne s'en rendront pas compte, ces webmasters ne ferons sûrement aucun effort pour changer, donc, concientiser les entreprise est important aussi et là, je fait confiance à beaucoup d'entre vous, moi, je reste à mon niveau d'amateur et ne tente d'évengéliser qu'a mon niveau (ce qui d'ailleurs n'est pas chose facile n'ayant pas la patience d'expliquer deux fois la même chose à quelqu'un qui ne comprend pas).

Haut retour au début de la page

2004.04.18 @ 19:51 par Denis

Bleizig, je comprends ton raisonnement, mais il est justement trop court-termiste et c'est précisément le point que j'essaie de soulever.

Brandir le flambeau des normes en disant que ça fera économiser des coûts comme par magie demeurera faux tant et aussi longtemps que les développeurs ne seront pas mis à jour dans leurs compétences. Ce qui est court-termiste présentement, c'est justement de réduire les enjeux à une équation trop simple... Il y a de nombreux facteurs outre le simple fait de développer plus efficacement qui viennt brouiller les cartes.

C'est de ces facteurs que je propose que nous tenions plus rigoureusement compte dans notre argumentaire, pour éviter que les décideurs ne s'emballent trop vite et n'abandonnent, déçus de ne pas avoir sauvé 50% de leurs coûts de production dès le premier essai. Nous savons tous que les normes permettent de mieux faire, plus rapidement. Ce que nous oublions parfois, c'est que la connaissance n'est pas tombée du ciel... Cette courbe d'apprentissage là, elle doit être quantifiée pour être en mesure de parler franchement au public des décideurs.

Tu écrivais :

'Si tout le monde, effrayé à l'idée de devoir débourser un peu, refusait le changement, nous n'irions pas très loin. Je pense que c'est la dessus qu'il faut argumenter au lieu de se limiter a une vision à très court terme.'

Ce à quoi j'ai répondu en disant simplement que je préfèrais largement redoubler d'effort pour les convaincre en mettant sur pied de réelles démonstrations documentées que de les attirer vers une guet-apens avec un pot de miel et une bébelle en prime.

Haut retour au début de la page

2004.04.19 @ 03:08 par Bleizig

'Bleizig, je comprends ton raisonnement, mais il est justement trop court-termiste'

Va falloir developper un peu plus la dessus car tu ne m'a pas convaincu que mon opinion de ne pas se limiter aux premiers couts mais de considerer la rentabilite a long terme etait court-termiste.

Haut retour au début de la page

2004.04.19 @ 04:39 par Eric Daspet

Que la transition entre deux méthodes soit chère ? c'est sûr, comme toute transition : il est toujours plus simple et moins cher de continuer une mauvaise méthode que d'en apprendre une meilleure.

Allons un peu plus loin que le court-terme. Ok, pendant 1 mois ça va couter beaucoup plus cher en développement, pendant 6 mois (un an pour être poli) ça va couter pareil voire légèrement plus cher. Par contre après les compétences seront là, la transition sera faite. Je ne parle pas tellement des personnes (qui peuvent aller et venir) mais des méthodes, des bases, des connaissances et compétences de l'entreprise.

De même le résultat lui entrainera tout de suite des gains, dès la première mise en place : maintenance, évolution, bande passante ...

Je ne sais pas si les gains du résultat vont compenser les pertes du à l'apprentissage pendant les premiers temps. Je ne me risquerai pas à un pronostique basé sur du vent. Par contre je suis convaincu que oui, moyennant un coût d'entrée (comme toute évolution), ça coute moins cher au final.

Ça s'appelle un investissement, tout bêtement. Sauf que là c'est un investissement pérènne et assuré en retour.

Haut retour au début de la page

2004.04.22 @ 05:45 par Elie Sloïm

Je suis tout à fait d'accord avec ce que dit Eric :

Ça s'appelle un investissement, tout bêtement. Sauf que là c'est un investissement pérènne et assuré en retour.

Le seul problème, c'est que même dans le camp des convaincus, tout le monde n'a pas les moyens d'investir.
Le problème est là.

Haut retour au début de la page

Les commentaires et trackbacks sont désormais fermés. Pour toute remarque, vous pouvez toujours nous contacter.

Pisteur (Trackback)