nota-bene.org > Sur le web > Pour une professionnalisation des métiers du web

Pour une professionnalisation des métiers du web

À propos de cet article

Un article de Stéphane

Publié le 4 septembre 2008

URL courte : http://nota-bene.org/274

12 commentaires

Il est temps que les sphères de décision des métiers du web intègrent une notion de plus en plus importante : le HTML, les CSS et le Javascript ne sont pas un effet secondaire des frameworks de développement. Ce sont des vrais langages, qui demandent une vraie compétence, pour savoir les utiliser au mieux et optimiser leur taille, leur rendu, bref : leur qualité.

Un constat

Voilà bientôt dix ans que je fréquente le milieu du développement web. En dix ans les métiers se sont diversifiés, spécialisés aussi.

Les langages serveur se sont petit à petit sophistiqués, et toute une génération de développeurs s’y est formée. Par exemple, les grandes entreprises ne jurent quasiment que par Java, et leurs systèmes d’information ont tous subi une mue radicale centrée sur le web.

Un effet dramatique de cette concentration a conduit les sphères de décision à envisager le HTML, les CSS et le Javascript comme des effets secondaires des langages serveur. La plupart des environnements de développement se sont surtout concentrés sur des couches d’abstraction, permettant d’écrire tout ce qui touche à l’aspect fonctionnel de l’application. Ensuite, une compilation plus loin, la couche client s’écrit toute seule.

Quelques exemples :

  • La validation de champs de formulaires est très souvent une usine à gaz, avec des tonnes de code Javascript, code très polyvalent puisque devant s’adapter à toutes les situations, mais loin d’être optimisé pour le formulaire dans lequel vous invoquez ce Javascript.
  • Le HTML n’est (à l’idéal de ces environnements) jamais directement atteignable. On finit par constater, impuissant, les aberrations de ce genre de technique.
    • Par exemple en ASP.net l’attribut alt qui permet de déclarer un texte alternatif pour une image est nommé altAttribute. Quand on pense comme il est difficile de motiver toute la chaîne de production d’un site à faire les choses le mieux possible, on imagine comme ils peuvent trouver d’autant plus ardu de devoir apprendre deux termes pour la même notion, et laborieux de taper un nom d’attribut aussi long.
    • Autre exemple : dans STRUTS il est impossible de mettre des en-têtes (th) dans une ligne de tableau de restitution de résultats.

Vous m’objecterez qu’il y aurait toujours moyen de modifier le framework lui-même. Je n’en doute pas, mais la plupart du temps c’est un tel casse-tête et ça demanderait un tel volume de travail, de présence et d’accompagnement qu’au final ce n’est pas fait. [1]

Les systèmes d’information des grandes entreprises, bien que très volontaires à l’idée de centrer leur activité sur le Web, ont fini par penser que le HTML s’écrit tout seul [2]. En exagérant à peine (voire en n’exagérant pas du tout si je m’appuie sur ma propre expérience), puisque ça marche dans leur Internet Explorer, alors tout va bien.

Les questions de maintenance de la couche client leurs sont étrangères. Les questions d’accessibilité sont accessoires, j’en ai déjà parlé ; sans compter qu’elles se posent généralement deux jours avant le lancement du site, comme une case à cocher dans le processus global de validation avant mise en ligne. [3]

Une énième anecdote

La semaine dernière, bonne âme, j’ai dépanné un développeur Java empêtré dans des règles CSS en cascade qui occasionnaient la disparition de blocs entiers d’un formulaire [4]. Le développeur, de façon empirique, sans absolument rien connaître des CSS sauf leur syntaxe, avait copié/collé tout un jeu d’instructions qui « semblaient faire ce qu’il voulait », instructions trouvées dans une autre partie de la CSS.

Il avait ensuite, au petit bonheur la chance, empilé des déclarations contradictoires, à tâtons.

J’ai passé quelques minutes à l’aider, à tâtons moi aussi pour commencer (une CSS énorme et peu de temps à disposition). Mon principe est toujours le même : commencer par expliquer que l’exercice de la CSS est un exercice zen. Il faut le moins de code possible, le moins d’instructions ; et laisser le maximum de libertés au navigateur, qui sait (la plupart du temps) très bien faire son travail.

Une pensée, comme toujours, pour le Tao du web design, qu’un jour nous devrons compléter par un article sur le zen de CSS : écrire le moins possible, apprendre à ne jamais écrire des règles qui se contrarient, s’appuyer sur l’implicite après quelques redéclarations (le fameux « reset » dont on a beaucoup parlé ces dernières années dans les milieux des spécialistes de CSS). Mais revenons à nos moutons.

J’ai pu constater à ce moment-là, encore une fois, comme souvent ces dernières années, la disparité entre la compétence des développeurs côté serveur et celle dont ils disposent côté client. Je ne les blâme évidemment pas : ils doivent acquérir un monceau de connaissances (entre les différents systèmes de gestion de version, les versions de Java et leur nommage abracadabrant, les spécificités du SI, etc.) et ils ne peuvent pas tout savoir.

(Pour conclure cette anecdote, le pauvre était pressé par le temps : je l’ai donc dispensé de mon laïus ex cathedra sur le besoin que son morceau d’application fonctionne sans javascript, sur le Javascript non intrusif, l’amélioration progressive... Toutes ces choses qu’un spécialiste de Javascript trouve aujourd’hui tellement naturelles. La dose de sophistication d’un développement côté client bien fait n’était plus atteignable si près de son échéance, sans compter l’effort qu’il avait déjà fait pour suivre les bricolages correctifs que je tentais en désespoir de cause.)

Travail en équipe

C’est là que je veux en venir : nous ne pouvons pas, ni les uns ni les autres, tout savoir et tout faire. Il est révolu, le temps où un seul développeur pouvait tout faire. Nous avons maintenant affaire à des projets d’ampleur, où un certain nombre de métiers interviennent.

Nous devons travailler en équipe. Or les sphères de décision l’ont déjà compris pour la majorité des métiers de la chaîne, à tel point que (tout de même) la première partie du montage HTML est souvent assurée par des « intégrateurs HTML » qui sont la plupart du temps capables de produire bien plus de choses que du simple HTML.

Nous venons de le voir, la vie d’un projet web n’est pas linéaire. Un schéma organisationnel simplifié pourrait ressembler à ceci :

  1. design graphique (un fichier image dans Photoshop)
  2. intégration du design : découpage images, HTML, CSS, Javascript
  3. développement côté serveur, intégration du HTML dans le code serveur.

Oui mais voilà : le projet n’est pas figé, et tandis que les grosses évolutions, les gros redesigns, les premiers lancements, pourront obéir au découpage schématique que je viens de décrire, la plupart du temps nous allons assister tout au long du projet à des évolutions techniques, par l’ajout de telle ou telle nouvelle fonctionnalité, de tel ou tel nouveau service.

Autrement dit, une fois la première grosse livraison effectuée, voilà le cycle d’évolution du projet :

  1. demande d’évolution technique
  2. développement par un développeur côté serveur
  3. constat qu’une partie de la couche client doit évoluer
  4. bricolage systématique par le développeur côté serveur.

C’est bien là que le bât blesse. En réalité, tout projet ambitieux comporte des évolutions permanentes et devrait faire appel à nouveau à « l’intégrateur HTML ». On ne peut que constater ici que son titre n’est pas adapté. C’est bien plus que de l’intégration, c’est du développement tout au long du projet qu’il s’agit : nous réfutons donc ce titre d’intégrateur et préférerons définitivement le titre de développeur web client.

Il faut, le plus possible, faire appel tout au long du projet à ce développeur. C’est une garantie de qualité : des CSS qui resteront le plus près possible du « zen CSS » évoqué ci-dessus, du HTML qui se voudra sémantique, etc. En bonus, le développeur web client peut aussi vous garantir l’adéquation à la charte graphique de votre entreprise, et (si vous prenez la peine de le laisser se former) un niveau homogène d’accessibilité.

Les hasards du calendrier

Au moment où j’écrivais les premières lignes de cet article, Élie Sloïm publiait un billet pour annoncer l’arrivée d’Aurélien Levy chez Temesis. J’y ai laissé presque tout de suite un commentaire, que je cite ici tel quel.

Dans le marketing ambiant, ils détonnent car au lieu d’annoncer leur qualité de "sachant", ils la démontrent.

Le truc que je trouve assez chiant (pardon my french), c’est exactement ça : le marketing ambiant. Le nombre de curriculum vitae que j’ai vus passer ces dernières années où les gens maîtrisent le HTML, le JS, et les CSS, sans compter XML, XSL et toute la clique des technos client.

Et puis après, tu leur donnes un éditeur texte, et tu vois qu’ils ne maîtrisent *en rien* les technologies client : elles sont, comme trop souvent, au mieux un effet secondaire de leurs développements serveur (parce qu’ils sont tous très forts en Java ou en PHP), au pire un truc facile à écrire et hors des tables point de salut. Sans compter une CSS approximative tout en pixels, du Javascript intrusif qui rend la page bloquante si on le désactive, etc.

Au final, les quelques rares personnes qui veulent vraiment "vivre de leur art", si je puis dire, et prônent un web client de qualité en ayant exactement les mêmes langages sur leur CV mais en sachant effectivement s’en servir passent pour des guignols (votre serviteur par exemple) parce que rien ne différencie leur CV de celui que je viens d’évoquer. En prime on est moins forts en PHP et en Java.

C’est dramatique pour la profession et la question est loin d’être aplanie.

... et ce sera ma conclusion : c’est dramatique pour la profession, et délicat pour le web client en général. Il faut donner une vraie légitimité aux développeurs web client, pour que les responsables de SI cessent de faire faire la couche client par des gens dont ce n’est pas le métier.


Notes

[1J’en ai déjà discuté avec des personnes chargées du déploiement d’un framework : faire des modifications spécifiques pour intégrer les problèmes liés à l’accessibilité pose des soucis. Comment, ensuite, intégrer facilement les versions ultérieures du framework sans devoir à chaque version réintégrer vos évolutions ? C’est coûteux et ça demande une attention impossible à tenir.

[2J’oubliais une précision pour ceux qui ne connaissent pas le monde de la Grande Entreprise : en Grandentreprisien, le terme « le HTML » englobe tous les langages de la couche client : HTML, CSS, Javascript.

[3Le 29 mai pour le 1er juin : Bonjour, nous lançons une nouvelle boutique / un nouveau portail. C’est le résultat de six mois de développement. Merci de vous assurer de son accessibilité. On en rit encore dans les chaumières.

[4Paragraphe technique à oublier pour les profanes : il empilait des float dans des conteneurs blindés de overflow:hidden et d’un tas d’autres règles qui se compliquaient la vie les unes les autres. Dans IE 6, l’effet était saisissant : hop, disparition du formulaire que le client était censé remplir !


Commentaires

    • 4 septembre 2008

    Stéphane, tu as bien raison, ils nous piquent notre boulot ces développeurs côté serveur !

    Trêve de plaisanteries, c’est effectivement catastrophique que les décideurs (pour la plupart) ne comprennent pas qu’une couche client bien faite et gage de satisfaction pour tous les visiteurs !

    En fait, ils n’ont aucune considération pour leurs visiteurs (clients ?), mais un jour, ça leur retombera sur le coin du pif et la je me marrerai, GNARFF !

    Répondre à sanvin

    • 4 septembre 2008

    Tout à fait d’accord.

    Un petit commentaire tout de même : Le processus ne devrai pas s’arrêter après le développement serveur. Il devrait repartir de zéro pour vérifier la cohérence du travail (sous-entendez que quelqu’un dans la chaîne n’a pas détruit le travail de son collègue précédent).

    Répondre à Neovov

    • 4 septembre 2008
    • en réponse à Neovov

    Le processus ne devrai pas s’arrêter après le développement serveur. Il devrait repartir de zéro pour vérifier la cohérence du travail.

    Oui mais bon, c’était un schéma très schématique pour montrer schématiquement le processus. Mon propos ici est de montrer qu’on n’est pas intégrateur mais développeur client, et que c’est un vrai métier.

    Répondre à Stéphane

    • 4 septembre 2008

    Très bon commentaire de biou qui en fait permettrait de faire tenir l’article ci-dessus en une phrase :

    Le problème est que la qualité ne se vend pas bien.

    Répondre à Stéphane

    • 4 septembre 2008

    Ca fait plaisir de te lire... C’est beau et triste à la fois.

    Répondre à STPo

    • 4 septembre 2008
    • en réponse à STPo

    Et encore STPo, tu me verrais imiter le chat qui a des régurgitations...

    Répondre à Stéphane

    • 4 septembre 2008

    Une situation triste en effet ... J’ai l’impression de participer à
    une croisade avec STPo et l’ensemble de notre pôle... et après
    beaucoup d’évangélisation on y parvient...

    Faire comprendre à l’ensemble de la chaine de production que notre
    activité ne correspond pas uniquement à pisser des lignes de code et
    que notre métier n’est pas aussi théorique et simple qu’il le parait,
    loin de là. Au-delà de l’accessibilité, on a même réussi à imposer la
    question de la performance dans les pages et applications web en
    reprenant nombreuses recommandations d’Eric Daspet et de Yahoo en
    générale ...

    Accrochez-vous !

    Répondre à Yves Van Goethem

    • 8 septembre 2008

    Billet intéressant, mais à relativiser. Les métiers du web client sont déjà entre les mains de professionnels, mais pas dans les mêmes sociétés. Schématiquement je dirais qu’il y a d’un côté des SSII qui développent des applications métier, avec des technos "sérieuses" (Java ou .Net) qui sont censées générer le code client. Celui-ci est donc le parent pauvre du projet, et les développeurs serveurs n’aiment pas trop y mettre la main.

    De l’autre il y a les agences où l’on trouve des développeurs clients très compétents (réussir à intégrer au pixel prêt sur tous les navigateurs certaines chartes graphiques est un exploit que je salue toujours). Ces "intégrateurs" sont déjà des "pros", même si le statut et le salaire suivent rarement.

    Les SSII commencent à comprendre et travaillent de plus en plus avec des agences, même si les deux monde ont encore besoin d’apprendre à communiquer et à se respecter.

    Là où je verrai plutôt un besoin de professionnalisation, c’est au niveau de ces trois langages que sont PHP, Javascript et ActionScript. Ils ont tous les trois un lourd passé de langage de bidouille, pas très sérieux, et donc snobé par les ingénieurs informaticiens. La plupart des développeurs de ma connaissance pratiquant l’un de ces langages n’a pas de formation en informatique. Or ce ne sont plus depuis longtemps les langages de bidouille qu’ils ont pu être. Je pense qu’il est donc grand temps de considérer qu’ils nécessitent des compétences en programmation, et donc de les former à la programmation. En espérant qu’ils soient ensuite reconnus comme des développeurs.

    Répondre à Clochix

    • 22 septembre 2008

    Moi qui vient du monde du développement côté serveur, ça correspond tout à fait à ce que je connais : fournitures de maquettes, développements serveur et bidouillages pour faire rentrer le HTML. Les développeurs Java proposés par les SSII connaissent rarement le développement côté client. Javascript, c’est bien le truc qui fait des onload et des onclick, et que si y’a des erreurs ba c’est pas grave, n’est-ce-pas ? Comme le dit Clochix, JavaScript a une bien mauvaise réputation. Ce qui compte, c’est le Java !! Depuis que j’ai changé d’activité et que j’ai découvert le développement client et l’accessibilité (grâce à toi notamment), j’évoque dès que j’en ai l’occasion l’importance du développement client. Malheureusement les bonnes pratiques passent encore trop souvent aux oubliettes. Mais un jour viendra...

    Nota Bene (ah ah ah) : je ne veux pas du tout dire que les “prestas” sont mauvais à côté des internes. Je n’en connaissais pas plus qu’eux sur le développement client, et moins sur le reste. C’est simplement un constat sur les développeurs disponibles que je déplore.

    Répondre à Laurent ROY

    • 28 mai 2009

    Moi aussi ça me donne envie de chialer.
    ho capitaine mon capitaine.

    Répondre à Etienne

    • 28 mai 2009
    • en réponse à Etienne

    Tu sais Etienne, mon message ne passera vraiment que si je te vois debout sur la table. sourire

    Répondre à Stéphane

    • 8 octobre 2010

    Complètement d’accord avec ça. Ces langages sont encore largement sous-estimés et le métier trop méconnu (ou ignoré) malheureusement. Il y a un vrai travail à faire encore de ce côté là tant au niveau des développeurs serveur mais également des chefs de projets ou des décideurs...

    Répondre à Sébastien

Qui êtes-vous ?
Votre message
  • Pour créer des paragraphes, laissez simplement des lignes vides. Tous les liens sortants comporteront un attribut rel="nofollow". Merci de ne pas spammer.

Ceci est la version Bureau Afficher la version Mobile