Super quali fragili web

Cet été, j’ai franchi le cap des 10 ans dans la même agence web. Officiellement « intégrateur HTML », j’ai porté différentes casquettes selon les clients et projets : j’ai eu droit à développeur front, lead développeur front, experte accessibilité, Madame Accessibilité, ou encore, la nana du Front.
J’aimerais revenir sur ma dernière mission qui m’a permis de comprendre qui j’étais, et le rôle que je devais prendre dans ce petit monde du web. Je vais donc vous parler d’un site que vous connaissez sûrement : laposte.fr.

La bonne volonté ne suffit pas

La fin de cette mission a été marquée par le départ du client, qui aujourd’hui ne passe plus par les services d’une agence externe. Je n’ai pas connu la longue période de passation, étant partie (au bon moment) en congé maternité.

Sur les nombreux sites sur lesquels j’ai pu intervenir, c’était le deuxième qui incluait dans ses spécifications fonctionnelles un « cahier des charges Accessibilité ». Le premier, c’était ma mission précédente : le site du groupe legroupe.laposte.fr1. J’étais donc déjà, comme qui dirait : pré-timbrée. On connaissait de l’accessibilité les principes de base, qui étaient surtout de bonnes pratiques que tout développeur doit, ou du moins devrait, connaitre. Avec le temps, je suis devenue en quelque sorte la référente en accessibilité ; non seulement ce sujet commençait à m’intéresser de plus en plus, mais surtout, j’avais compris qu’il y avait un vrai besoin, car personne à part moi ne s’y intéressait dans l’agence.

Sur un projet de cette envergure, on ne peut pas se contenter de compter uniquement sur la bonne volonté individuelle de chaque intervenant. Nous travaillions alors avec un prestataire en charge de l’accessibilité, mais son rôle était limité à faire des audits sur un produit fini. Les développeurs, front et back, avaient bénéficié d’une formation sur 2 jours qui consistait à lire le RGAA2. C’était bien, mais loin d’être suffisant.

Surtout quand je constatais les éternels retours du prestataire, relevant toujours les mêmes problèmes. Les développeurs étaient pourtant formés, alors pourquoi des audits toujours aussi décevants ? Qu’est-ce qu’on pouvait bien faire de plus que de leur demander d’apprendre le RGAA par cœur ? Mais ceux qui le connaissent un tant soit peu, savent que cela ne s’adresse pas uniquement aux développeurs. J’avais déjà là le premier élément de ma réponse.

Le second concernait bien le code, mais il fallait trouver comment pouvoir intervenir de la bonne façon, autrement qu’en tapant sur les doigts à coup de RGAA.

Première étape

J’ai commencé par revoir notre workflow, parce qu’on commence toujours par balayer devant chez soi. Première étape : aucun développement Front ne sera livré s’il ne passe pas d’abord ma validation.

Je me chargeais donc de vérifier chaque merge request, et mon attention portait sur les points suivants3 :

  1. prise en compte de l’accessibilité et des bonnes pratiques
  2. respect de la charte graphique
  3. prise en compte de l’existant sans surcouche inutile

En parallèle, je capitalisais les développements effectués. Après un à deux ans de développement, on pouvait dire qu’on avait tout fait en terme de composant, et la majorité des nouveaux projets étaient principalement constitués de formulaires.

La solution pour ce projet aurait été d’avoir un styleguide, facile à maintenir et à faire évoluer. Et bien, ce fut pourtant bien l’idée de départ, on avait tout ce qu’il fallait : une architecture pensée modulaire, un générateur de styleguide (KSS), un accord dans l’équipe pour ne livrer que des composants, et aucune page « toute faite ». Il y eut un moment, je ne sais plus comment, mais ça a dérapé. Et impossible de revenir en arrière : « le client veut pouvoir valider les pages en front ». Il me semble aussi qu’au même moment, arrivaient de nouveaux chefs de projets… hasard, coïncidence… ?

Soit, les développeurs back ont du coup sauté sur l’occasion pour me faire comprendre qu’ils n’aimaient pas trop mes idées de composants, que c’était plus facile pour eux de copier une page, et surtout ça leur permettait de vérifier visuellement ce qu’ils avaient intégré, en jouant au jeu des 7 erreurs avec les pages statiques du front.

Mais quelle bande de …

J’avoue avoir pensé dans un premier temps : mais quelle bande de feignants. Mais j’ai vite compris qu’en fait, le dev back il aime pas l’HTML. Et je ne peux pas lui en vouloir, après tout c’est pas son métier.
J’étais donc face à 2 méthodes insatisfaisantes.

Celle où le développeur back récupère mes composants a comme avantage de m’éviter de monter 10 pages de déclinaisons de formulaires. Au mieux je relivre mon styleguide qui comporte déjà tous mes composants, au pire, je fais une page d’exemple qui contient tous les champs possibles. Elle a par contre comme inconvénient d’imposer au développeur back de chercher et d’intégrer les bons morceaux d’HTML, et de construire lui-même la page. Et c’est là qu’on perd donc en qualité, puisque comme je l’ai déjà dit : le dev back, il fait du back.

L’autre méthode, qui consiste à livrer à l’équipe back des pages toutes faites iso maquette, son avantage, c’est de rassurer. Que ce soit le chef de projet qui voit la maquette s’animer, le client qui saisit l’avancement, le dev back qui peut comparer. Son inconvénient n’est pas des moindres : une perte de temps ! Et oui, on a beau faire 10 fois un champ email, ce ne sera jamais deux fois le même. (par contre son identifiant lui, risque souvent de l’être).

J’ouvre une petite parenthèse pour expliquer pourquoi 10 champs email ne peuvent être identiques.
Soit 10 champs email créés sur plusieurs pages différentes : pour s’inscrire à une newsletter, pour s’identifier, pour contacter, pour commenter, … Déjà ceux qui passent l’étape de la créa pour ressortir identiques sont peux nombreux… Ceux ensuite qui passent dans les mains de l’intégrateur, qui suit scrupuleusement les maquettes, ou pas.

Et puis vient la phase de recette, un ticket Jira qui portera seulement sur le formulaire de contact par exemple…

Puis quelques mois plus tard, une fois le site en prod… on en avait combien déjà de champs email ? Qui s’en rappelle encore ? Qui pensera à tous les vérifier ?

Je referme la parenthèse.

Mais on fait comment alors ?

Et bien, afin d’éviter les allers-retours entre front et back, et faciliter le jeu des sept erreurs, nous avons donc testé une nouvelle méthode : je développais et maintenais d’un côté les sources front qui servaient avant tout de modèle, et qui constituaient mon styleguide. Et d’un autre côté j’avais désormais accès aux sources back pour y intégrer directement mes composants dans les templates Twig.

Résultat : on gagne du temps à ne construire les pages qu’une seule fois, et on libère le développeur back de ce qu’il n’aime souvent pas faire. Et surtout, je pouvais m’assurer de la qualité et du respect des critères d’accessibilité du livrable front, jusqu’au bout du back !

Allons au-delà de la tech

Assurer une bonne entente entre le front et le back, c’est bien. Mais ce n’est, encore une fois, pas suffisant. J’en parlais tout à l’heure, une partie du RGAA ne concerne pas le code, mais la conception.

Il fallait que je trouve un moyen pour atteindre une sphère quasi intouchable : les UX, et les DA. Pas facile, surtout quand on est tech.

Et bien je crois que c’est aujourd’hui dans ma carrière, ma plus grande fierté : obtenir 2 cycles de formations et une sensibilisation pour plus d’une vingtaine de personnes au total.

D’abord, une séance de sensibilisation à l’accessibilité, pour tous les profils de l’équipe, qu’ils soient tech, créa, chef de projet ou même QA.
Ensuite, on se focalise sur ceux qui pilotent le projet et qui testent : leur donner les clefs pour gérer l’accessibilité, afin qu’ils puissent savoir non seulement « Quoi », mais aussi « Comment ».
Et pour finir, on renoue les liens avec les concepteurs et les DA : des formations ateliers pour faire de la conception accessible. Parce que ce n’est pas la faute du développeur si les messages d’erreur d’un formulaire ne sont pas clairs…

Je dois dire que lorsque les invitations furent lancées, la motivation n’était pas au rendez-vous. J’ai lourdement insisté pour avoir tout le monde à la première étape clef de sensibilisation, celle qui permet de susciter l’intérêt et la curiosité, pour donner envie de continuer. Et bien, parfois, il faut savoir être lourd. Car aujourd’hui encore je reçois des retours de ces formations, ceux qui auraient aimé en bénéficier, ceux qui me livrent de magnifiques maquettes, ou encore ceux qui en veulent toujours plus.

Certains manquent encore à l’appel

Avec ces formations, on avait enfin une équipe de choc, à tous les niveaux. Enfin presque… il restait une étape clef : la contribution.

Ce n’est pas une mince affaire car il s’agit non seulement de former les webmasters, mais aussi le client et/ou sa propre équipe de webmasters. Et surtout, pouvoir ensuite remonter les potentiels problèmes rencontrés, comme par exemple : en insérant une image dans une page, est-ce qu’on a la possibilité de renseigner un texte alternatif ? Si ce n’est pas le cas, cela nécessitera un retour aux équipes back afin de faire évoluer le CMS (si toutefois l’évolution est possible).

Vous l’aurez donc compris, l’accessibilité à ce niveau représente potentiellement un gros chantier. Au delà de la formation, il s’agirait de tester en amont le CMS, afin de prévoir directement les développements supplémentaires nécessaires. Et ensuite, former les personnes en charge de la contribution.

Je n’ai hélas jamais pu atteindre ce dernier point, et ce pour plusieurs raisons : un départ du client, une dissolution de l’équipe, un congé maternité… on prend les mêmes et on recommence.

Bonjour Madame, merci Madame

On a vu l’importance de la communication inter-métiers, de chercher comment améliorer le quotidien et le travail de chacun. L’importance de placer les bonnes personnes et de les reconnaître.

J’aurais aimé que mon manager se soucie de cela… à ma place. Nous ne pensons aujourd’hui qu’en termes de projet : on ne manage plus des personnes, on manage un budget, un produit.
Parce qu’optimiser un environnement de travail, des outils, des méthodologies, transmettre un savoir, ça ne se vend pas. Pourtant c’est aussi un travail, du temps que j’ai dépensé, entre deux tickets Jira.

Je pense avoir aujourd’hui trouvé une bonne recette, du moins je sais comment accorder mes ingrédients.
Ne plus perdre son temps : identifier les problèmes, identifier les besoins, trouver les solutions et tout faire pour les appliquer. Et ne jamais oublier de valoriser les acquis.

Lorsque vous ferez un audit d’accessibilité de votre site ou tenterez de répondre à un client qui s’interroge sur votre niveau de conformité, posez-vous les bonnes questions avant d’envisager la moindre action.

Quel est le niveau de connaissance de vos développeurs ? A quel point vos concepteurs et créatifs sont-ils sensibilisés ? Avez-vous déjà piloté un projet exigeant d’être accessible ?
Et surtout quel sera votre degré d’exigence ?

Pour répondre à ces questions, vous n’aurez d’autre choix que de discuter avec tous les métiers : et c’est ainsi que commencera à s’établir votre plan d’action.
Et peut-être qu’un jour, comme moi, vous ne pourrez plus vous en passer.

    Notes

  1. La Poste possède plusieurs sites. Nous avons principalement : legroupe.laposte.fr : site institutionnel concernant l’entreprise elle-même, laposte.fr : concerne les services que propose l’entreprise, et encore boutique.laposte.fr : le site e‑commerce.
  2. RGAA = Référentiel Général d’Accessibilité pour les Administrations.
  3. Je ne vérifiais principalement que le code sans tester le rendu : je connaissais tellement ce site que je pouvais le voir à travers la matrice… Et surtout, mon rôle était avant tout de filtrer, pas non plus de perdre du temps à vouloir trop en vérifier ou devenir QA.

3 commentaires sur cet article

  1. Ana Maïa, le mardi 12 décembre 2017 à 09:39

    Merci pour ton article, en tant que fronteuse convaincue par l’accessibilité ça fait plaisir de lire ce genre de retour et de voir comment tu as pu mettre tout ça en place dans ton équipe ! :)

  2. STPo, le mardi 12 décembre 2017 à 20:03

    Bravo madame, merci madame. Et que ça file droit !

  3. Emilie, le vendredi 15 décembre 2017 à 14:25

    Merci :)