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 » !)

9 commentaires sur “Faut-il maîtriser son code HTML ?”

  • N'est-ce pas plutôt là une indication de la qualité d'un framework IHM ? Même sans référencement, intégrer un montage est une étable obligatoire. Quand on voit la facilité à le faire avec Wicket ou Struts 2 et son système de templating, on se dit que JSF ou autres joyeusetés du même genre sont réellement en retrait (et pas que sur ce point). Le cas de GWT est un peu différent, car il s'agit d'un framework tourné vers la réalisation "d'applications web", l'objectif n'est donc pas le même.
  • Il n'y a pas que le framework d'IHM qui est à remettre en cause, mais souvent le processus d'échange avec les designer. A une époque ou nous parlons d'équipe Scrum et de rapprochemet MOE/MOA afin que chacun soit conscients des problèmes rencontrés par les équipes. Quand à Wicket, cela n'est pas non plus la solution miracle car il encourage à ajouter des attributs qui ne sont pas html strict compliant. Et le code dans la partie "Controller" de l'application et loin d'être propre. Pour conclure, et pour rester proche de l'idéologie Scrum : mieux vaut privilégier les processus et la communication que les outils.
  • Je te rejoins sur ton analyse Damien, le framework est loin d'être le seul responsable mais il y contribue. Quand toujours dans les projets, ce qui pose le plus souci est la manière dont les gens travaillent ensemble. Favoriser les échanges est l'une des clés majeures pour réussir un projet.
  • Je vous rejoint sur la séparation entre le "One size doesn’t fit all", les contraintes sont tellement éloignées entre un site de e-commerce et une application de gestion. Un argument en faveur de la maitrise du code HTML pour les sites Web : les performances. Les générateurs de code HTML produisent le plus souvent du code très verbeux.
  • Ravi qu'Octo se positionne sur ce sujet. Cela fait quand même 4 ou 5 ans que le problème crucial de la maitrise du code des pages Web d'une application devient un élément fondateur de la maitrise d'un parc logiciel et de l'"outillage" des process dans une entreprise (les orchestrateurs intertsidéraux mettant ce sujet sur le tapis la plupart du temps). Ceux qui n'ont pas réalisé à temps que l'arrivée de navigateurs innovants et la popularisation de standards du Web désormais matures auront attendu 2009 pour réfléchir à la problématique de Frameworks IHM. Mais mieux vaut tard.... Je pensais de manière désabusée que le niveau du dernier petit déjeuner Octo organisé sur ce sujet cristallisait ce peu de maîtrise de la problématique et de ces enjeux, me voilà rassuré.
  • Où l'on apprend tout de même qu'on met du HTML dans les jsf... hum... Je ne suis pas absolument sûr que cela soit dans les bonnes pratiques.
  • Merci pour ce post qui parle d'une problématique réelle du terrain et qui met un petit bémol à GWT. On vient de passer des années à engranger des connaissances sur le HTML/CSS et on oublie tres souvent en parlant de GWT (le must have actuel...) que le travail des designers ne pourra plus etre intégré comme avant... Alors OK pour les petites applications rapides mais meme pour une application intranet, le HTML/CSS est important! Je dirais que si on a plus de 100 utilisateurs alors le HTML/CSS est important. En dessous de 20 alors on peut se fier au design du développeur... (j'en fais partie :) Maintenant, peut-etre qu'un framework comme ZK qui a un langage XML permettant d'intégrer du HTML et des CSS pourrait un jour dépasser GWT... Ou alors les designers doivent se spécialiser à la techno GWT. En tous cas, on peut également citer Spring MVC avec son système d'annotations vraiment très efficace et qui (nous) permet de travailler avec nos designers. Apres il y a encore le sujet d'avoir un designer dans une équipe agile, mais ca c'est un autre sujet...:) Merci encore. Gilles
  • Je pense qu'il ne faut non plus confondre ergonomie et design. Le design c'est ce qui fait que l'on vient sur un site. L'ergonomie c'est ce qui fait que l'on y revient. Dans les applications d'entreprise, le design faut bien avouer qu'on s'en fou puisque les utilisateurs seront obligés d'y venir. Du minimaliste convient donc souvent ("a la" google). Par contre l'ergonomie reste un besoin important et est souvent mal pris en compte alors que c'est ce qui va de paire avec la productivité. Les ergonomes (contrairement aux designers) n'en ont "rien" à faire du html, du css etc. Ils ne font que prendre en compte les limitations du support. Ensuite il donnent diverses recommandations sur les enchaînements des actions, le positionnement des éléments etc. Le framework importe donc peu pour ce qui est de l'ergo mais le fait de maîtriser le généré (comme le code généré d'ailleurs) reste un point important pour la maîtrise globale des développements.
  • Ce qui est sur, c'est que d'experience, quand on fait faire du Html un peu joli à un dévelopeur java en mode agile donc "rapidement", le résultat est un code Html pas très très propre... :) Après d'experience également, meme pour une application intranet d'entreprise, l'ergonomie est très importante pour faciliter/encourager la participation des gens sans devoir gérer des emails et appels téléphoniques pour accompagner les gens... (encore une fois quand la population concernée est supérieure à 100)
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha