Faut-il maîtriser son code HTML ?

Un lundi matin, de bonne heure (10h53), bureau « des développeurs », le téléphone sonne…
– Allo Jean ? C’est Michel de l’équipe des designers, je viens de t’envoyer la nouvelle maquette HTML pour le site institutionnel, tu peux le mettre à jour dans l’environnement de test pour une démo cette semaine ?
– Oui, pas de soucis, on se lance dans cette intégration avec mon équipe, je te tiens au jus, bonne journée !

Mercredi, fin de journée (17h48), même bureau
– Allo Michel, c’est Jean, on a une première version du site à te montrer, je t’envoie l’URL
– Mince, j’attendais à avoir le résultat plus rapidement pour le montrer à la direction, attend je regarde… Eh ! Mais il n’y a que la première page, je pensais avoir le site complet !
– Ecoute Michel, j’ai déjà sorti d’un autre projet 2 gars de l’équipe pour faire ça, on a fait de notre mieux pour l’intégrer au plus vite
– Mais, attend, c’est tout décalé et plus du tout conforme à ce que je t’avais envoyé
– …on a fait au mieux je te dis, nos composants ne permettaient pas de générer exactement les balises HTML que tu nous a données, on a même dû en customiser quelques uns et on est pas sûr des effets de bord sur nos pages actuelles
– Et mon CSS, pourquoi vous l’avez modifié ?
– Euh, ça c’est le framework qu’on utilise qui a ses propres classes, donc on a dû faire face à des conflits, d’ailleurs ça nous a bien pris 2H pour corriger ça !
– Mais pourtant c’est pas bien compliqué le HTML, j’en fais tous les jours et je ne suis pas développeur moi !
– Oui, mais de notre côté on doit passer du temps à intégrer ton HTML avec notre framework IHM…

Vous êtes-vous déjà retrouvé dans ce genre de situation ?

Vous vous prénommez Jean ou Michel et vous avez justement eu cette discussion ce matin même ?

Trouvez vous normal que ce que votre équipe de designer met une journée à réaliser, vous ne pouvez l’intégrer en moins de 3 jours ? Le problème viendrait-il seulement d’un mauvais choix de framework IHM ?

Les différentes approches des frameworks IHM

Les frameworks IHM n’ont pas tous la même approche avec la création d’applications Web. Certains comme GWT vous dispensent de vous soucier du HTML et le produit à votre place, à partir de vos instructions Java. D’autres comme Wicket s’appuient entièrement sur votre code HTML existant, auxquel vous ajoutez des comportements. JSF se situe entre les deux, vous modifiez le code HTML en apportant les balises JSF qui vont elles-mêmes se transformer en code HTML. Quelle est la bonne approche ? Faut-il forcément maîtriser son code HTML ?

Quels sont mes cas d’usage ?

Qu’elle soit internet ou intranet, une application web se doit de faire la distinction entre sa partie informationnelle/publique et sa partie transactionnelle/privée.

Pour la première partie, par exemple un catalogue de produits ou de l’information éditoriale, les objectifs de référencement et d’accessibilité imposent une maîtrise du code HTML produit (qu’il soit écrit par le développeur/webdesigner ou généré par le framework IHM).

Dans le second cas, par exemple un formulaire de commande ou bien l’affichage de données propres au client, les contraintes ne sont pas aussi fortes, notamment sur la nécessité de référencement. On peut ainsi sacrifier la « propreté » du HTML généré en échange d’un gain de productivité apporté par le framework.

Avantages de la maîtrise du code HTML

La collaboration avec des designers

Le travail de design d’un site Internet étant un travail à part entière, il est la plupart du temps délégué à une équipe dédiée ou une agence Web. Cette équipe n’a souvent aucune idée du framework IHM que les développeurs vont utiliser, elle construit le code HTML final que les utilisateurs et moteurs de recherche obtiendront.

Avec GWT par exemple, nous n’allons pas pouvoir utiliser pleinement le travail produit par les designers. L’équipe de développement va produire son code Java en essayant de s’approcher au maximum du rendu graphique de la maquette HTML, malheureusement le code HTML généré par GWT ne sera pas identique à celui produit par les designers. Un long travail d’intégration et de nombreux tâtonnements sont à prévoir…

En utilisant JSF, nous pourrions nous dire que c’est plus simple puisque nous allons partir de la maquette HTML pour y changer quelques balises par des balises JSF. Le souci est que le remplacement de ces quelques balises va introduire de nombreux changements et des effets collatéraux. Tout d’abord, ces balises JSF vont générer du code HTML et des styles CSS dont nous n’aurons plus la totale maîtrise et qui peuvent potentiellement rentrer en conflit avec ceux créés par les designers. Au final, en tant que développeur, on se retrouve à faire intervenir les designers continuellement pour obtenir un code HTML et des styles CSS proches du résultat souhaité. La frustration est grande car les deux équipes produisent beaucoup d’effort pour un accouchement difficile !

Avec ces 2 approches, les douleurs dues au travail pour obtenir la première intégration se répètent lors des itérations suivantes : si le code final HTML doit évoluer, le développeur doit à nouveau (souvent par tâtonnements successifs) faire en sorte que son code génère les modifications HTML demandées.

L’approche différente proposée par Wicket prend toute sa signification dans ce contexte puisque les modifications apportées vont être simplement l’ajout d’attributs (principalement wicket:id) aux éléments HTML auxquels on souhaite ajouter un comportement. Le travail réalisé par les designers peut alors être totalement réutilisé par l’équipe de développement. Non seulement, les développeurs ne perdront pas de temps à se conformer à la maquette HTML mais les designers n’auront plus à intervenir dans le projet et le résultat final sera identique à leur maquette.

De plus, lors des itérations suivantes, la modification du HTML par les designers pourra toujours se faire sur la même base et être réintégrée immédiatement sans que le développeur ait à la retravailler. La seule condition étant que l’outil du designer préserve les attributs Wicket lors des modifications (testé et approuvé avec Dreamweaver et Aptana)

Le besoin d’un référencement optimisé

Pour un site Internet, le référencement est une étape cruciale qui ne doit pas être négligée. Un bon référencement permet d’augmenter significativement le nombre de visiteurs d’un site et ainsi de se faire connaître auprès d’un large public. Arriver parmi les premiers résultats d’un moteur de recherche comme Google assure infiniment plus de trafic, peu de gens consultent l’ensemble de la première page (pour vous en convaincre, rendez-vous à l’université du SI cet été où une démonstration d’outils Eye Tracking sera réalisée). C’est pourquoi des techniques d’optimisation pour les moteurs de recherche (SEO) sont nées. Certaines de ces optimisations nécessitent un bon contrôle de balises HTML. Maîtriser son code HTML pour respecter les préconisations des webmasters spécialisés en SEO est donc important.

La volonté de rendre son site accessible

Malheureusement souvent oubliée, l’accessibilité des applications Internet est un enjeu non négligeable si votre site est à destination d’un large public. Pour en comprendre les enjeux et les implications, consultez notre article sur l’accessibilité du web (partie 2). L’accessibilité vous amènera à suivre les recommandations et les normes du consortium W3C, ce qui vous sera facilité par le contrôle de votre HTML. Le 16 mai, le décret n°2009-546 a été publié dans le Journal Officiel imposant aux établissements publiques de conformer leurs sites Internet aux normes d’accessibilités.

Cas d’une application Intranet

L’absence de maquette HTML, de besoin de référencement et d’accessibilité

Toutes les applications Web n’ont pas pour vocation la publication sur Internet, certaines ne seront disponibles qu’aux utilisateurs d’une société. On rentre alors dans le cas des applications Intranet. Lors du développement de ce type d’applications nous ne disposons pas toujours de maquette HTML, des écrans présentant l’emplacement et les types de blocs suffisent, et le développeur joue souvent le rôle de designer (avec un résultat plus ou moins réussi, nous sommes les premiers à l’avouer !). On ne recherche pas à maîtriser l’emplacement des éléments au pixel près mais à être fidèle aux fonctionnalités de chaque écran et disposer d’une bonne ergonomie. Maîtriser le code HTML n’est donc pas une priorité contrairement à la productivité des développements, à l’usabilité. Dans ce cas, avoir à manipuler exclusivement du code Java, comme le fait GWT, est un avantage en terme de productivité. On reste ainsi dans les compétences bien connues et maîtrisées des développeurs Java, on cesse de chercher à former une équipe de moutons à 5 pattes qui connaissent les technologies JSP, JSTL, XHTML, JSF, RichFaces, Spring WebFlow…

La maîtrise du parc des navigateurs Web

Autre point important avec les applications Intranet : le contrôle du parc informatique. Les navigateurs utilisés sur internet sont multiples, ce qui n’est pas le cas en entreprise : une version précise d’un navigateur Web a été choisie au niveau de l’entreprise pour l’utilisation des applications. On évite ainsi les différences de comportements entre les navigateurs et le temps passé à s’assurer que l’application fonctionne avec tous les navigateurs du marché. Ne pas maîtrisez son code HTML (ou davantage son code JavaScript et CSS car c’est souvent sur ces points que les standards adoptés par les navigateurs diffèrent) est dans ce contexte moins gênant.

Attention toutefois à ne pas tomber dans la facilité qui consiste à réaliser un code ne visant la compatibilité qu’avec une version de navigateur donnée. Les montés de versions pourraient alors être problématiques voire impossibles, alors qu’elles sont souvent imposées tôt ou tard pour des contraintes de sécurité, ou de maintenance arrivée à expiration. Ces considérations doivent donc nous pousser à réaliser du code respectant un minimum les normes du W3C.

Conclusion

Selon le type de l’application Web que vous souhaitez créer, les contraintes ne sont pas les mêmes et influent sur les priorités du projet et donc le choix du framework IHM.

Dans le cas d’une application Intranet, on peut considérer les framework offrant une bonne productivité de développement et de maintenance, au détriment d’une moins bonne maîtrise du code HTML.

En revanche pour un site Internet grand public ou BtoB, les contraintes sont différentes : navigateurs multiples, enjeu de référencement, et collaboration avec les designers rendent indispensables la maîtrise du code HTML. L’utilisation d’un framework IHM qui, comme Wicket, propose une approche de la manipulation du code produit par les designers non destructive, est clairement un bénéfice dans ce genre de projet. Avec JSF ou GWT, respecter à la lettre le code HTML souhaité par les designers et webmasters sera une douleur qui aboutira malheureusement à des compromis.

Ces considérations peuvent donc amener à faire cohabiter plusieurs framework IHM dans une même entreprise pour des besoins différents (« One size doesn’t fit all » !)