Agences et Standards Web - 2. Migrer vers les standards

Openweb.eu.org > Articles  > Agences et Standards Web - 2. Migrer vers les standards

Abstract

En ce début d’année 2006, après quatre années à promouvoir les standards et l’accessibilité du web, il est temps de voir si ces idées ont faites leur chemin dans le milieu professionnel du web. Nous avons donc rédigé une série de 18 questions que nous avons posées à quatre professionnels chacun ayant son approche, son vécu et sa façon d’utiliser et de produire du code standard et accessible. Ce qui démontre si besoin est, que bien qu’utilisant des standards communs, la diversité est plus que jamais présente chez les professionnels du web...

Article

Cette série d'interviews croisés est présentée en cinq parties :

Migrer vers les standards

OpenWeb — Cela fait-il longtemps que votre agence fait des sites conformes aux standards ? Qu'est-ce qui vous a poussé à cela ?

Ph. Lecocq, Business interactif — Nous avons commencé à prendre en compte les recommandations du W3C avec les feuilles des styles niveau 2, il y a maintenant deux ans. La séparation de la forme et du contenu nous permet de faire des sites plus structurés et facilite la maintenance. Le contexte était favorable puisque les navigateurs non conformes comme IE4 et Nescape 4.7 n'entraient plus dans nos chartes de montage.

Puis, suite à la parution du projet de loi du 28 janvier 2004 "pour l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées", nous avons, dans le cadre de la maintenance de nos sites de l'administration publique, anticipé les futurs besoins en intégrant progressivement les recommandations du WAI relatives à l'accessibilité.

En juin 2005, Chronopost, notre premier site conforme et accessible niveau 3, était mis en ligne.

L. Gloaguen, Cosmic Communication — Ça a commencé doucement en 2003. Avant, les CSS n'étaient pour nous qu'un moyen d'affecter du style à des textes, et de faire quelques gadgets visuels, comme des fonds de page fixes. Je ne savais même pas qu'il était possible de faire une maquette entièrement en CSS... Quant à savoir ce qu'était un "doctype", c'était juste une ligne complètement obscure et facultative que certains éditeurs s'obstinaient à vouloir placer, rien de plus. Et si le code était en bas de casse, c'était tout simplement parce que je trouvais cela plus plaisant à l'oeil. Pour nous, un site Web, c'était avant tout du "slicing", du découpage de maquettes Photoshop sous Image Ready... C'est dire comme on partait de loin.

Ma première confrontation avec une maquette au code conforme et entièrement en CSS pour le graphisme, sans "soupe de balises", je l'ai eu en installant Movable Type en 2002, un CMS de blogues. Je ne comprenais pas comment la mise en page fonctionnait, alors j'ai tenté de bidouiller, je me suis vite énervé, pour enfin me documenter et apprendre sur le tas. Je dois dire que mes découvertes dans le domaine sont très liées à mon expérience du blogue et de la blogosphère. Non seulement, j'étais face à de nouvelles façons de réaliser des sites via les outils de publication, mais aussi, la lecture de certains carnets Web m'apportait beaucoup d'informations précieuses. Je dois énormément à des gens comme Karl Dubost, Tristan Nitot, Denis Boudreau, etc. C'est grâce à eux que j'ai été sensibilisé aux enjeux des standards et des bonnes pratiques de la programmation Web. Sans eux, mon agence produirait probablement aujourd'hui encore des sites "vieille école", lourds, difficiles à gérer, et bien sûr complètement invalides et inaccessibles...

R. Ode, B&DI Eolas — La recherche d'un critère de qualité technique pour les sites Internet, le respect des standards du W3C nous ont naturellement conduit vers l'accessibilité et ses conséquences directes (l'accès complet d'un site Internet aux handicapés), les conséquences secondaires nous ont confortées dans cette direction : atouts pour le référencement, personnalisation de l'impression, du matériel de visualisation (PDA, webTV, feuilles de style...), facilité de maintenance, etc. Ce faisceau de preuve nous a convaincu que toute autre voie (site Internet construit autour de Flash, intégration graphique basée sur les tableaux, non utilisation significative des balises, ignorance des CSS 2 etc.) est une mauvaise direction.

D. Molina, N. Levieil, P. Prieto et A. Brin, SQLI — En tant que designer HTML, nous travaillons avant tout sur l'interface, nous avons pour mission de concevoir pour chaque projet web la maquette HTML qui sera intégrée par les équipes techniques (ingénieurs SQLI, prestataire ou le client lui même). Les maquettes que nous produisons sont conformes aux standards en vigueur : HTML4 ou XHTML. Le respect des standards a commencé à devenir réaliste - vis-à-vis des contraintes auxquelles peut être soumise une maquette HTML : navigateur, outil de gestion de contenu... - il y a 2 ans environ. Pour les designers HTML, cela se concrétise par un code plus propre et plus simple, donc aussi plus léger et plus souple. Des documents plus lisibles, plus simples à coder et à mettre à jour. La souplesse apportée par la séparation contenu/présentation est l'un des arguments clés de la migration vers le respect des standards.

OpenWeb — Comment avez vous (et votre équipe technique) ressenti/vécu la période de transition qui a peut être suivi ? Où en êtes-vous aujourd'hui ?

Ph. Lecocq, Business interactif — Il a d'abord fallu faire une mise à niveau de nos connaissances et revoir nos façons de faire. Jusqu'alors, le monteur html était un autodidacte, " bidouilleur de code ", qui mettait son sens pratique en oeuvre pour rendre compatibles des pages sur tout un parc de navigateurs de différentes générations. Depuis la décision d'abandonner les navigateurs dépassés et d'utiliser systématiquement les feuilles de styles, nous avons redécouvert le sens des balises HTML. Beaucoup d'entre elles avait été détournées ou n'étaient plus utilisées. Forcement, un tel changement a eu des conséquences sur l'organisation des projets, nos contraintes sont devenues celles des autres (chefs de projet, concepteurs, graphistes et développeurs) : au début les temps de montage ont eu tendance à rallonger. Les concepteurs on dû prendre en compte nos besoins et les notions de gabarits et de structure de document sont devenus des problématiques très concrètes pour tout le monde. Sans tableau, ni attribut de mise en forme, les équipes de développement ont dû à leur tour revoir leurs méthodes d'intégration.

Aujourd'hui, nous avons assimilé ces changements, nos sites y ont gagnés en cohérence et en structuration. Nous faisons attention à ce que toutes les pages qui sortent de l' «atelier montage» soit conformes et valides.

L. Gloaguen, Cosmic Communication — La transition a été progressive, en douceur, au rythme des apprentissages. Elle fut vécue comme une évolution du métier positive et très motivante. Une bouffée d'air frais... Aujourd'hui, il y a toujours à apprendre, à perfectionner, et c'est très stimulant.

R. Ode, B&DI Eolas — La transition n'a pas été simple car a changé radicalement la conception graphique, ergonomique, technique d'un site Internet au sein de l'entreprise. Il fallut d'abord convaincre du bien fondé de cette démarche, c'est un changement qui remet en cause jusqu'aux connaissances de chacun, des sessions de formation ont pu ensuite être menées vers les membres de l'entreprise pendant une année complète. Nous pouvons dire que de manière générale, tout le monde est à jour dans sa méthode de travail et la conception web.

D. Molina, N. Levieil, P. Prieto et A. Brin, SQLI — C'est avant tout la méthode de conception des structures de pages qui a évoluée : abandonner la construction par tableaux, maîtriser parfaitement la sémantique HTML et le potentiel du langage CSS, évidemment tout cela s'apprend. Le partage d'expériences est essentiel pour faire évoluer l'expertise de chacun. Avec du recul, on constate que c'était la compatibilité du "rendu" navigateur (le duo Explorer/Navigator) qui primait, aujourd'hui ces derniers évoluent, et ce sont désormais la sémantique du contenu et la modularité qui priment. Et bien sûr, toute nos maquettes passent aujourd'hui par le validateur W3C.

OpenWeb — Quelles sont les principales difficultés que vous avez rencontré durant ce changement ?

Ph. Lecocq, Business interactif — Côté montage, le plus long est de faire évoluer les mentalités. Comment demander à un monteur rapide et efficace en montage "old school" d'arrêter les tableaux et les calages à l'image transparente au profit d'un montage "full css" respectant la structure du contenu ? Il faut du temps et de la pratique pour intégrer ces problématiques et que cela devienne naturel. Côté développement, les contraintes liées au langage ou à la plateforme, entrent parfois en conflit avec le respect des standards.

L. Gloaguen, Cosmic Communication — La seule vraie difficulté, à mon avis, ce sont les navigateurs obsolètes qui sont encore sur le marché. Cela nous oblige à cuisiner les CSS avec des bidouilles, les fameux "hacks". Ce n'est pas propre et ça fait perdre du temps. C'est même philosophiquement antinomique avec l'esprit de "standards du Web". Heureusement, le marché s'assainit de lui-même mois après mois.

R. Ode, B&DI Eolas — La conviction que la voie du respect des standards et de la norme ne laisse pas sur le chemin d'autres aspects importants d'un site Internet (temps de réalisation, esthétisme, référencement, maintenance etc.), nous savons maintenant, après avoir capitalisé les compétences nécessaires que ce n'est pas le cas, mais que tout est dans la méthode. Ces difficultés ne se seraient pas levées aussi facilement sans l'opiniâtreté de certains ;-)

D. Molina, N. Levieil, P. Prieto et A. Brin, SQLI — De prime abord, le respect strict des standards peut être perçu comme une contrainte vis-à-vis du design à reproduire, notamment du fait de la mauvaise interprétation ou de l'implémentation incomplète des standards par les navigateurs. Dans la pratique, on constate qu'un codage conforme aux standards peut provoquer plus de soucis qu'il n'en résout toujours parce que nous devons tenir compte des spécificités des navigateurs des futurs utilisateurs. Nous devons alors identifier au cas par cas les solutions qui permettront de faire en sorte que tout fonctionne. Compte tenu des exigences, le design que nous devons reproduire est généralement complexe et de ce fait, la conception entièrement CSS doit encore trop reposer sur les fameux hacks, et demande donc non seulement une grande expertise mais aussi et surtout de l'expérience !

OpenWeb — Cette migration a t-elle eu des impacts sur votre représentation du Web et de ses services. Si oui lesquels ?

Ph. Lecocq, Business interactif — L'impact le plus important est la prise de conscience de l'accessibilité : d'un seul coup, on s'est rendu compte qu'on pouvait contribuer à un web citoyen, ça a vraiment motivé tout le monde.

L. Gloaguen, Cosmic Communication — Le Web est pour moi avant tout constitué d'usages, donc, non, les standards du Web (qui ont toujours existé) et les bonnes pratiques de développement n'ont pas changé ma représentation du Web, juste celle de mon métier, principalement en exigeant un niveau qualitatif supérieur de la production.

R. Ode, B&DI Eolas — On ne peut pas parler de migration car cela est plus profond, ce ne sont pas le web et les services qui ont subit des changements, leur évolution est la même qu'auparavant. En revanche, un outil de gestion de contenu à haute accessibilité respectant les standards permet de diffuser ces services à un spectre d'utilisateurs infiniment plus large qu'auparavant et de manière personnalisée. C'est une certaine appropriation des services et des contenus qui est née.

Lire la troisème partie de cette série d'interviews: 3. Utiliser les standards.

À propos de cet article

Vos commentaires

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?
Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom