Pour une professionnalisation des métiers du web

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.