Penser l’expérience de contribution pour améliorer la qualité de nos sites

Guillaume Barbier ~ 24 minutes

Beaucoup de sites web reposent sur des systèmes de gestion de contenu (CMS). En tant que concepteurs et conceptrices de ces systèmes, nous tenons à ce que les sites qu’ils génèrent soient de bonne qualité. Lors de leur initialisation, nous nous assurons qu’ils s’affichent correctement sur une vaste variété d’appareils et qu’ils soient performants, accessibles et bien référencés.
Pourtant, quelques mois après la mise en ligne, nous nous rendons parfois compte que la qualité s’est dégradée, même sans évolutions apportées de notre côté.

Mais pourquoi la qualité de nos sites baisse après leur mise en ligne ?

Parce que, souvent, le dernier maillon de la chaîne de production a été insuffisamment pris en compte. En effet, la vie d’un site ne s’arrête pas à la livraison de notre code. Une fois le CMS livré, il est pris en main par des personnes essentielles, qui seront chargées de remplir l’écrin vide que nous avons fourni et lui donner vie : les contributeurs et contributrices.

Ce sont les utilisateur·rices intermédiaires de nos solutions. Ce sont les personnes qui vont, avec les outils que nous leur avons fournis, travailler à produire la meilleure expérience possible pour nos utilisateur·rices finaux : les internautes.

Malheureusement, si beaucoup d’efforts sont fournis pour nos utilisateur·rices finaux (Recherche utilisateurs, Design d’interface et d’animation…), il est assez rare que nous pensions à nos contributeur·rices. Et cette négligence peut parfois avoir un effet négatif sur la qualité de nos sites et donc l’expérience de nos utilisateur·rices finaux.

Sommaire

Un premier exemple pour illustrer

Le problème

Il y a quelques années de cela, sur un site dont je m’occupais, un audit d’accessibilité a révélé que presque toutes les pages contenaient des paragraphes vides. En investiguant un peu, nous nous sommes rendu compte que beaucoup de ces paragraphes vides étaient dus aux en-têtes de nos pages : la description censée apparaître sous le titre <h1> (titre de niveau 1) de la page était très souvent générée sans contenu. Ces descriptions étant obligatoires, il n’était en théorie pas possible de passer outre (et pourtant…).

Les causes

Pour identifier l’origine du problème et la corriger, nous avons étudié les contenus en production et sommes allés à la rencontre de l’équipe de contribution. Voici ce que nous avons découvert :

  • une obligation subie, en inadéquation avec leurs besoins. Les contributeur·rices étaient souvent gêné·es par cette obligation d’avoir une description. Soit parce qu’ils ou elles n’avaient pas d’idée de description à fournir, soit parce qu’elle les empêchait d’afficher plus haut dans la page des contenus jugés prioritaires ;
  • des individus créatifs découvrant une astuce. Certaines personnes se sont rendu compte qu’en saisissant une espace insécable dans le champ « Description », il était possible de valider la saisie sans réellement rédiger de description. L’astuce a été communiquée à toute l’équipe de contribution et même enseignée aux nouveaux membres de l’équipe, non pas comme une astuce de contournement mais comme une méthode de contribution : Tu peux ignorer les champs textes obligatoires en insérant une espace insécable ;
  • des effets de bords invisibles. Cette petite astuce était parfaitement satisfaisante pour l’équipe de contribution, n’ayant pour seul effet visible qu’une marge légèrement plus importante sous le titre.

La résolution

Pour résoudre ce problème, il a été décidé, avec les responsables du site, de prendre en compte les besoins de l’équipe de contribution et nous avons rendu le champ optionnel, en stipulant qu’en cas de champ vide, aucun paragraphe ne serait généré.

Il s’agit ici d’un exemple assez simple de problème de contribution pouvant mener à une baisse de qualité d’un site. La suite de cet article va détailler quelques causes possibles d’erreurs de contribution, tout en proposant des solutions pour y pallier.

Préambule

L’expérience de contribution varie grandement d’un CMS à un autre, pouvant aller d’une interface très intuitive, où ce que l’on voit est ce qui sera restitué (aussi connu sous l’acronyme WYSIWYG, soit « What You See Is What You Get » ou « Ce Que Vous Voyez Est Ce Que Vous Obtenez »), à une interface composée d’une succession de formulaires, sans restitution du contenu contribué (par exemple dans le cas de CMS headless)…
Il serait arrogant de prétendre tous les connaître, c’est pourquoi les conseils donnés dans cet article s’efforceront d’être les plus agnostiques possibles.

Erreurs de contribution : les origines

Afin d’éviter les erreurs de contribution, il est important d’en comprendre les causes et les mécanismes. Par exemple, ce que nous considérons comme une erreur n’est pas forcément perçu ainsi par nos contributeur·rices : certaines de ces erreurs peuvent être aussi perçues comme des astuces ou des solutions de contournements.

Aborder les contributions inattendues avec bienveillance.

Lorsque vous abordez ces contributions inattendues avec vos contributeur·rices, il est important de se montrer bienveillant·e et d’essayer de comprendre ce qui les a amené·es à cette contribution, en gardant en tête qu’il y a très probablement une logique derrière.

Manque de compréhension : ambiguïtés et défaut d’information

Je n’ai pas compris comment le composant s’utilisait.

Certaines erreurs de contribution viennent d’une méconnaissance ou d’une incompréhension de la finalité des outils mis à disposition. Cela peut venir d’un défaut d’information (documentation absente, incomplète, ou tout simplement pas consultée) ou d’une difficulté à comprendre les usages (paramètres contre-intuitifs, documentation inadaptée à la cible…).

La contribution manquante

Parfois un contributeur ou une contributrice peut ne pas avoir identifié qu’un champ était nécessaire pour l’usage visé.

Exemple : un contributeur laissant le champ « title » vide pour un lien s’ouvrant dans un nouvel onglet, ne sachant pas que dans ce cas d’usage, il est nécessaire de le renseigner avec le libellé complet du lien et une mention « (s’ouvre dans une nouvelle fenêtre) ».

Contributions antagonistes

Certaines saisies peuvent entrer en conflit et provoquer un rendu bancal, voire non fonctionnel. C’est un cas de figure assez fréquemment rencontré avec des fonctionnalités très (trop ?) versatiles, ou dans des WYSIWYG autorisant une (trop ?) grande liberté d’association des contenus.

Exemple : une contributrice insérant un lien dans une tuile déjà intégralement cliquable (avec son propre lien) et ne sachant pas que cela le rend quasiment impossible à activer.

Méconnaissance de la finalité d’une fonctionnalité

Les contributeur·rices peuvent parfois utiliser une fonctionnalité produisant un résultat en apparence proche de leurs objectifs mais avec des effets de bords imprévus, car n’ayant pas été conçue pour cet usage.

Exemple : un contributeur utilise un composant qui présente une série de liens sous forme de cards afin de créer un damier d’une vingtaine de cards, sans savoir que le composant en question est réservé à des contenus annexes, venant en complément du contenu principal de la page.
Résultat, sur mobile, sa page se retrouve réduite à un titre et un carrousel d’une vingtaine de slides.

Les évolutions des usages

L’affichage de ce composant ne nous convient plus, on a trouvé une astuce pour en utiliser un autre à la place.

Avec le temps, les besoins des équipes de contribution peuvent évoluer et les fonctionnalités proposées ne plus leur convenir. Dans ces cas-là, elles vont tenter d’y répondre avec les outils à leur disposition et peuvent parfois faire preuve d’une grande créativité. Malheureusement, leur inventivité ne prend souvent pas en compte les effets de bord invisibles : erreurs d’accessibilité visibles uniquement dans le code, erreurs d’affichage sur mobile, erreurs en bout de parcours utilisateurs…

Premier exemple : le problème des descriptions vides, présenté en début d’article, est en partie lié au fait que le besoin d’afficher des contenus importants plus haut dans la page n’avait pas été identifié sur les premières pages produites avec le gabarit concerné. Ce besoin n’est apparu que lorsque l’usage du gabarit s’est généralisé à l’ensemble du site.

Deuxième exemple : le cas du damier de cards présenté plus haut pour illustrer la méconnaissance de la finalité d’une fonctionnalité relève aussi de l’apparition d’un besoin nouveau.

Troisième exemple :

  • contexte : l’équipe de contribution doit intégrer sur le site des bannières vers un site partenaire, mais celui-ci a des exigences de mise en page incompatibles avec les bannières du site ;
  • la solution trouvée par l’équipe de contribution : détourner l’usage habituel des bannières, en ne saisissant pas le libellé du lien et en utilisant un visuel de bannière contenant le libellé directement intégré dans l’image, selon la charte du partenaire ;
  • le résultat : il apparaît relativement propre sur leurs ordinateurs, mais porte en fait de nombreux problèmes, dont des textes inaccessibles et une image rognée sur mobile, masquant une partie du texte.

Le principal levier pour éviter ce genre de situation (ou du moins pour y remédier rapidement) est de maintenir ouvert un canal d’échange entre les équipes de développement et de contribution, pour permettre à cette dernière de remonter ses besoins d’évolution. Ce canal peut prendre de multiples formes, allant d’un processus très cadré impliquant des outils de gestion de tickets, à un canal dédié dans un outil de messagerie instantanée, en passant par des réunions régulières impliquant les contributeur·rices ou des représentant·es.

La pénibilité

Une autre source d’erreur est la pénibilité des tâches. Plus une tâche de contribution est longue, fastidieuse ou répétitive, plus les risques de générer des erreurs augmentent. Un risque d’autant magnifié si l’intérêt de renseigner certaines informations n’est pas clair pour la personne chargée de la contribution.

La tâche répétitive

L’aspect répétitif de certaines tâches peut amener nos contributeur·rices à faire des erreurs de saisie par inattention.

Exemple : une contributrice doit inverser la position de deux entrées dans une page FAQ. La tâche est a priori simple mais notre contributrice fait face à plusieurs limitations du CMS :

  • la page a été conçue avec une succession de composants « Titre » et « Paragraphe » (chaque entrée de la FAQ contient les deux) ;
  • l’interface du CMS n’affiche aucune différence entre les différents composants : pour connaître la nature d’un composant, il faut ouvrir la boîte de dialogue correspondante ;
  • l’interface du CMS ne propose pas de solution pour déplacer du contenu à un emplacement précis. La seule option disponible est « déplacer le contenu à la fin ».

Notre contributrice doit donc déplacer les quatre composants constituant les deux entrées à inverser, ainsi que tous les autres composants se trouvant initialement en dessous, sans jamais se tromper dans l’ordre des composants « Titre » et « Paragraphe ». Le risque d’erreur pour cette tâche est très important.

La tâche (en apparence) dénuée de sens

Si une tâche paraît superflue ou inutile, elle risque de ne pas être effectuée, par souci d’économie de temps. Un effort de documentation ou de sensibilisation des équipes peut aider à limiter ce genre d’erreur, mais cette approche a ses limites. Si la tâche est particulièrement pénible ou fastidieuse, nos contributeur·rices auront tendance à ignorer nos recommandations.

Exemple : nous souhaitons afficher un répertoire de médias à télécharger sur notre site, pour les mettre à disposition de nos partenaires. Pour la contribution de ces contenus, notre développeur·se a décidé de forcer la contribution manuelle du poids des fichiers pour que les contributeur·rices prennent conscience du poids des médias qu’ils ou elles ajoutent.
Quelques mois après la livraison de la fonctionnalité, nous nous rendons compte que la plupart des médias sont proposés en téléchargement sur notre site avec un miraculeux poids de « 0 Ko ». L’équipe de contribution, ne voyant pas l’intérêt de ce champ, l’a laissé systématiquement vide, plutôt que de perdre son temps à chercher comment connaître le poids d’un fichier en « Ko ».

Des astuces pour limiter les erreurs

Après avoir exploré ce qui peut pousser les équipes de contribution à ne pas utiliser notre CMS tel que nous l’avions imaginé, il reste à trouver comment éviter, comment limiter, ces contributions inappropriées. La liste d’astuces qui suit n’est pas exhaustive mais devrait tout de même se montrer utile.

Une documentation claire et disponible

Nous l’avons déjà évoqué, la documentation a un rôle important dans la prévention des erreurs. Mais son effet peut être grandement réduit si l’on ne fait pas attention aux points suivants :

  • disponibilité : votre documentation doit être mise à disposition de vos équipes de contribution. Elle doit se trouver à un emplacement auquel chaque membre de l’équipe a accès et, bien entendu, cet emplacement doit leur avoir été communiqué ;
  • adaptation : lors de la rédaction de votre documentation, il est important de savoir à qui elle s’adresse. Pour vos équipes de développement, vous pouvez entrer dans des considérations techniques assez poussées. En revanche, pour vos équipes de contribution, ces considérations techniques risquent d’être source de confusion. Tentez de connaître le degré d’appétence numérique de vos contributeur·rices afin de jauger le niveau de détail technique à fournir (et isolez les considérations techniques dans des pages ou des encarts dédiés) ;
  • navigation par tâches : si vos développeur·euses apprécieront une documentation axée sur le découpage technique des fonctionnalités, vos contributeur·rices préféreront une documentation qui liste les tâches à effectuer et détaille comment les réaliser ;
  • expliquer la finalité : un bon moyen de guider les contributeur·rices est d’expliquer la finalité des différentes options de contributions, en se concentrant sur leur utilité pour les internautes plutôt que sur leurs impacts techniques.

Travailler la dénomination des options

La façon dont nous présentons les options de contribution a un impact sur leur usage. Sans comprendre les implications des choix effectués, le risque d’erreur augmente. Pour pallier cela, il faut s’intéresser à leur présentation.

L’approche la plus naturelle pour les concepteur·rices est de s’intéresser au phénomène, à l’effet produit :
Exemple de champ orienté « effet » : un champ intitulé « Couleur du message », proposant les options « Rouge », « Jaune » et « Bleu ». Avec cette approche, nos contributeur·rices s’intéresseront à l’effet visuel et seront guidé·es par leur sens du goût, qui peut grandement varier d’un individu à un autre.

À la place, nous pouvons axer le même champ sur la finalité, la raison pour laquelle chaque option est proposée :
Exemple de champ orienté « finalité » : un champ intitulé « Type de message », proposant les options « Alerte », « Avertissement » et « Information ».
Avec cette approche, nos contributeur·rices seront guidé·es par l’intention du message à afficher. Rappeler la finalité dans les libellés de nos champs permet aussi aux équipes de contribution de repérer plus facilement quand la fonctionnalité ne correspond pas (plus) à leurs usages et qu’il est nécessaire de demander une évolution.

Cette approche orientée « finalité » a aussi pour avantage d’être plus robuste dans le temps : en cas de refonte de la charte du site, les options proposées dans ce deuxième exemple resteront valides, contrairement aux options de couleurs, qui pourraient devenir obsolètes.

Des stratégies pour gérer les contributions erronées

Malgré toutes les précautions prises en amont, il est inévitable que des erreurs se glissent dans les contributions. Il faut donc anticiper ces erreurs et établir des stratégies pour les gérer. Ces stratégies peuvent être regroupées en trois catégories :

  1. Bloquer les contributions erronées
  2. Autoriser les erreurs, mais les rendre impossibles à ignorer
  3. Autoriser les erreurs, mais limiter leur impact

Ces différentes stratégies ont toutes leurs propres limites (détaillées plus loin) et souvent la gestion des erreurs se fera en en combinant plusieurs. Par exemple, le blocage (stratégie numéro 1) pour les erreurs les plus simples peut être combiné avec une stratégie plus permissive (stratégies numéro 2 ou numéro 3) pour les cas trop complexes pour être bloqués. Il s’agit de trouver l’équilibre entre fiabilité et flexibilité.

Trouver l’équilibre entre fiabilité et flexibilité.

Note : Pour plus de confort de contribution, il est recommandé d’essayer de conserver une certaine cohérence dans les stratégies utilisées : une fois que vous avez choisi de gérer un type de contribution d’une certaine manière, assurez-vous d’opter pour la même approche pour les contenus similaires. Des changements inattendus de stratégie peuvent troubler et frustrer vos contributeur·rices.

1. Bloquer : poser des limites

Avec cette approche, la contribution est cadrée de manière à empêcher les erreurs de contribution, en bloquant la validation ou le rendu en cas d’erreur. Pour cela, de nombreux outils peuvent être utilisés :

  • empêcher les saisies erronées :
    • champs obligatoires ;
    • validation des champs ;
    • listes d’options prédéfinies (définies lors du développement ou dans des interfaces de contributions réservées à des profils avancés) ;
    • champs liés : la disponibilité de certains champs ou options est conditionnée aux choix faits dans d’autres champs
  • empêcher le rendu de contributions erronées :
    • conditions minimales d’affichage : si la saisie ne respecte pas certaines combinaisons de critères prédéfinis, la fonctionnalité concernée n’est pas affichée. Cette approche est particulièrement pertinente quand le CMS ne permet pas de définir des champs ou des options liées ou lorsque le rendu est dépendant d’autres sources d’informations (contributions dans un contexte plus large, réponses d’API…).

Cette approche a cependant des inconvénients :

  • plus la fonctionnalité est versatile, plus cette approche est difficile à implémenter ;
  • si les limites ne sont pas comprises des équipes de contribution (et si elles ne sont pas adaptées à leurs besoins), elles peuvent les pousser à trouver des astuces aux effets délétères (comme dans notre tout premier exemple en début d’article).

2. Autoriser : signaler les erreurs

Cette approche consiste à ne pas bloquer la contribution mais à s’assurer que la restitution du composant ne puisse pas être considérée comme valide par nos contributeur·rices, afin de les pousser à la corriger.

L’objectif ici est d’éviter ce que l’on pourrait appeler des erreurs silencieuses : des erreurs discrètes ou invisibles à première vue, soit parce que perceptibles uniquement dans certains cas d’usage (résolution mobile, usage d’une technologie d’assistance…), soit parce qu’elles sont liées à un parcours utilisateur très spécifique.

Cette stratégie peut prendre la forme de messages d’avertissement dans l’interface de contribution ou d’une apparence dégradée, tant que ce principe clef est respecté : les contributeur·rices doivent pouvoir constater l’inadéquation de leur contribution avant la publication.

Pratique lorsqu’il n’est pas possible de bloquer certaines contributions ou qu’une dégradation gracieuse (stratégie suivante) n’est pas possible, cette stratégie comporte tout de même un gros inconvénient : la notion de ce qu’est une apparence acceptable ou dégradée est hautement subjective et varie d’un individu à un autre. De plus, elle implique que le CMS permette de vérifier facilement le résultat avant publication (et que les équipes de contribution prennent le temps de le faire).

3. Autoriser : dégradation gracieuse

Avec cette approche, des exceptions sont prévues pour toutes les erreurs de contribution (saisie manquante, options incompatibles…), afin de garantir un affichage acceptable. Il s’agit de l’approche idéale, alliant fiabilité et confort de contribution… en théorie.

L’approche idéale… en théorie.

En effet, il peut être particulièrement difficile de prévoir tous les cas d’usages possibles d’un composant et cette approche comporte aussi le risque de transformer notre fonctionnalité en une usine à gaz difficile à maintenir.

L’autre difficulté communément rencontrée avec cette approche est l’arbitrage qu’il est nécessaire de faire entre les différentes dégradations possibles de la fonctionnalité, pour déterminer la plus souhaitable.

Utiliser des valeurs par défaut

Les valeurs par défaut sont un excellent moyen de limiter la pénibilité de la contribution, tout en permettant de gérer certaines erreurs.

Ainsi, des valeurs par défaut bien pensées peuvent permettre de faire gagner du temps aux équipes de contribution. Par exemple, définir une taille de texte par défaut, basée sur la taille de texte la plus communément utilisée sur le site, évitera d’avoir à la sélectionner à chaque ajout d’un bloc de texte.

Les valeurs par défaut peuvent aussi servir à garantir la présence de libellés sur des éléments d’interface critiques.

Exemple : pour les interfaces de recherche du site, nous voulons que les contributeur·rices puissent personnaliser le libellé du bouton « Afficher plus de résultats » pour avoir « Afficher plus d’offres » sur la recherche d’offres d’emplois et « Afficher plus de formations » sur la recherche de formations. Implémenter « Afficher plus de résultats » comme valeur par défaut permet de s’assurer que toutes les pages affichent un libellé pour ce bouton, même si cette personnalisation a été oubliée.

Les valeurs par défaut peuvent être gérées de deux manières, chacune avec ses avantages et inconvénients.

Les champs préremplis

Avec cette méthode, lors de l’initialisation d’un contenu, certains champs sont préremplis avec une valeur définie par le système. Ce qui permet donc de faire l’économie de cette saisie ou la modifier si besoin.

Cette approche est très utile sur les champs optionnels, mais dont la contribution est recommandée. En effet, il est tout de même possible de vider le champ et ainsi ne pas utiliser la valeur suggérée.

En revanche, elle peut avoir l’inconvénient, avec certains CMS, de rendre les évolutions compliquées. Si l’on fait évoluer la valeur par défaut, celle-ci peut ne pas être mise à jour automatiquement sur les contenus existants, la donnée ayant été définie à l’initialisation de ceux-ci.

Application en cas de défaut de saisie

Cette méthode consiste à appliquer une valeur définie au préalable quand l’information attendue n’a pas été fournie ou est incorrecte.

Elle a le mérite d’assurer une forme de limite douce sur des informations obligatoires : la contribution n’est pas bloquée et il est possible d’ignorer le champ, mais le système s’assure qu’une information sera utilisée pour garantir son bon fonctionnement.

En revanche, cette approche a le tort d’être invisible : le contributeur peut ignorer son existence (et donc ne pas en profiter ou, au contraire, ne pas être conscient des impacts de la non-saisie, la fonctionnalité restant opérationnelle).
Pour pallier ça, il est recommandé d’informer de ce garde-fou lors de la saisie, à l’aide d’infobulles ou autres textes d’aide.

Penser l’expérience contributeur

Cet article nous a permis de découvrir plusieurs cas d’erreurs de contribution et des outils pour les prévenir.

Les notions clés à retenir :

  • il est important de prendre en compte vos contributeur·rices ainsi que leurs contraintes (de temps, d’appétence numérique,…) ;
  • la conception d’interfaces de contribution est un jeu d’équilibre entre les besoins des utilisateur·rices (intermédiaires et finaux) et les contraintes techniques de notre solution CMS.

Connaître ses contributeur·rices

Apprendre à connaître les personnes qui composent vos équipes de contribution est un élément clef de la démarche.
Cela peut se faire plus ou moins directement, avec ou sans intermédiaires, à l’oral ou par écrit.

L’important est de s’intéresser non seulement à leurs appétences techniques, mais aussi à leur capacité d’investissement dans le CMS (les équipes de contribution ont-elles d’autres attributions ? Ont-elles le temps de se former ?…).

S’intéresser à leur métier peut aussi s’avérer fructueux, en vous aidant à comprendre et anticiper leurs besoins. Par exemple, dans le milieu des banques aux particuliers, il est régulièrement nécessaire de mettre en avant des portions de textes avec des tailles de texte supérieures, pour des raisons légales. Si nous souhaitons éviter que nos contributeur·rices n’émaillent les pages du site de titres <h2> indiquant « Un crédit vous engage… », il est nécessaire de leur mettre à disposition un style adapté, si possible pouvant être appliqué sur une portion de texte.

Une affaire d’équilibre

En pensant l’expérience de contribution, vous allez inévitablement devoir faire des choix entre le confort, la fiabilité et la flexibilité, ainsi que diverses contraintes techniques :

  • les limites de l’interface (WYSIWYG, formulaires bruts, types de champs disponibles…) ;
  • la complexité des règles de gestions implémentées.

Il est difficile de donner des conseils génériques sur ce sujet, mais voici quelques points à surveiller lorsque vous tentez de définir un point d’équilibre :

  • prenez en compte la maintenabilité de votre système : plus une fonctionnalité est complexe, plus elle est lourde à maintenir ;
  • méfiez-vous des contraintes trop importantes : elles encouragent la créativité ;
  • méfiez-vous aussi de l’hyper-flexibilité : une fonctionnalité qui fait tout risque de ne rien faire bien ;
  • évitez de tordre le cou aux principes fondateurs de votre CMS, sauf cas de force majeure. Cela ouvre la porte à des anomalies dont vous pourriez vous passer et complique les montées de version.

Enfin, si votre interface de contribution est très limitée et vous empêche de fournir un niveau d’assistance satisfaisant directement dans l’interface, n’oubliez pas que vous avez d’autres moyens d’accompagner vos équipes : documentation, tutoriels (écrits ou vidéos) ou encore sessions de formation.

Il n’est plus possible de laisser un commentaire sur les articles mais la discussion continue sur les réseaux sociaux :