But : que les produits électroniques juridiques soient facilement et donc massivement utilisés

Petit guide de conception des plateformes et bases de données juridiques en ligne — Recommandations en matière de moteurs de recherche, ergonomie, conception graphique, mise en page et contrôle qualité à destination des SSII et éditeurs juridiques

Les habitudes et présupposés des juristes dictent la majorité des choix ... mais pas tous

Samedi 5 novembre 2011, par Emmanuel Barthe // L’édition juridique

[article rédigé en 2007 et mis à jour depuis.
Ajouts novembre 2011 :

  • accessibilité web
  • contrôle qualité du contenu.
    Modifications juillet 2013 :
  • moteurs sémantiques / classement par pertinence]

Les spécialistes de l’interrogation des bases de données juridiques, qui sont aussi des formateurs, constatent que beaucoup d’éditeurs juridiques rééditent des erreurs de conception de leurs produits en ligne pourtant déjà dénoncées cent fois ailleurs. Depuis 1996, ainsi, Jakob Nielsen, dans ses études payantes détaillées et sa chronique hebdomadaire gratuite AlertBox sur Useit.com conseille les sites marchands et insiste sur l’importance de se conformer aux habitudes des internautes et à des standards de facto dérivés des grands sites web. Un nombre important des conseils listés ici font partie de que Nielsen et d’autres spécialistes appelent l’"usabilité" ou plus correctement utilisabilité ou facilité d’usage (en anglais "usability" [1]).

L’auteur du présent petit guide voudrait aussi partager ici ce qu’il a dégagé de plus de dix ans de tests d’interfaces informatiques de toute nature en documentation juridique : banques de données ASCII [2], logiciels, cédéroms monoposte et réseau/multiposte [3], sites web, plateformes web en ligne.

Sécuriser la propriété intellectuelle

C’est une évidence pour les juristes en PI (propriété intellectuelle) mais il faut le rappeler. Pour créer une base de données, et a fortiori une plateforme en ligne regroupant des dizaines de base, il faut que les contrats d’auteur aient prévu la publication numérique et en ligne et les cessions de droits à cet effet. Si seul le papier était couvert, il faut renégocier avec les auteurs. Autant dire qu’il est certain que certains auteurs refuseront, pour des motifs x ou y. La base de données sera alors non exhaustive.

Or s’il y a bien un présupposé des juristes vis-à-vis d’une base de données, en ligne, c’est qu’elle est exhaustive. Il vaut donc mieux éviter de les décevoir.

Rationaliser la chaîne de production éditoriale

En vrac :

  • ne plus accepter d’articles ne respectant pas les normes de présentation et de citation
  • exiger des auteurs la copie de tout document cité non présent sur la plateforme de l’éditeur, notamment les décisions de justice et circulaires inédites, et (en les numérisant et OCRisant si nécessaire) intégrer ces documents dans la plateforme
  • demander aux auteurs de saisir leur article/étude à partir d’une interface en ligne. Les documents seront ainsi formatés idéalement dès le départ et cela évitera d’avoir à les re-saisir.

La contrainte des standards de facto

Les juristes ont des habitudes d’utilisation de l’informatique et d’Internet largement déterminées par quatre principales influences : les logiciels de bureautique, les grands sites web les plus utilisés (Google, Amazon, etc.)

- Les logiciels bureautiques standard : la gamme Office de Microsoft, à commencer par Word, et Acrobat Reader. Ces logiciels influencent d’abord les attentes en matière de :

  • positionnement et intitulé des menus/fonctionnalités. Exemple : si on fait un clic droit sur un document, on accède à des fonctions de base d’édition : police de caractères, ...
  • manipulation/déplacement des documents. Exemple : maintenir un clic gauche de la souris puis la déplacer déplace le document.

- Les grands sites web les plus utilisés : moteurs de recherche, sites de commerce en ligne et sites de communautés en ligne (forums de discussion, sites de vidéos en ligne et jeux en ligne notamment). Ce sont eux qui créent les standards de facto du design web. L’ergonomie des plateformes en ligne a intérêt à s’inspirer de Google, YouTube, Amazon, Wikipedia, etc., notamment pour l’existence et le placement de certaines fonctionnalités critiques comme :

  • le site doit être complet et à jour. Il s’agit à la fois d’une exigence professionnelle normale et d’un présupposé de 90% des internautes — pour eux, le en ligne est par définition parfaitement à jour [4] :
    • toutes les rubriques doivent être actives. A défaut, indiquer "Site en construction" dès la page d’accueil ou les retirer
    • chaque page doit comporter une date de dernière mise à jour ou, idéalement, de fraîcheur (date à laquelle les informations contenues dans la page étaient à jour)
  • l’Aide : dans le coin en haut à droite, sinon, pour l’aide contextuelle, juste à droite de la fonctionnalité en cause
  • l’accès au compte utilisateur : en haut à droite avant l’Aide
  • le plan du site. En matière de plateformes en ligne juridiques, cela revient à la fois à la liste de toutes les bases de données/publications, classées par source du droit (textes, jurisprudence, doctrine) et/ou par matière mais aussi au détail du contenu exact de chacune des bases (recul chronologique, "trous" éventuels, producteur des données, périodicité effective de mise à jour, titres et auteurs des publications incluses)
  • navigation : garder le sommaire et l’index alphabétique comme accès aux ouvrages et revues [5]. Certaines notions ne se réduisent pas à une requête booléenne, aussi fine soit-elle, ni à une navigation dans un thésaurus, ni à un classement par popularité. Elles peuvent aussi être voulues et/ou spécifiques à un auteur
  • la recherche sur le site/la base de données :
    • à placer en haut à droite si la recherche n’est pas la fonction numéro 1 du site, sinon légèrement sur la gauche à un tiers de la hauteur
    • offrir deux modes de recherche : simple avec un zone de saisie libre balayant tous les champs texte et éventuellement un champ date/période, avancée avec tous les champs interrogeables ou presque et l’utilisation des opérateurs booléens.
      A propos de la recherche simple, il est vital que même chez celle-ci, on trouve un champ date/période.
      A propos de la recherche avancée, de nombreux éditeurs ou webmestres estiment qu’ils peuvent se dispenser d’en offrir une, car elle est peu utilisée. Le problème, c’est qu’ainsi, les requêtes/questions difficiles ne trouvent pas de réponse (cf infra) et que si l’utilisateur est expérimenté dans son domaine juridique ou expert des bases de données (documentaliste, juriste "geek"), il y a de fortes chances qu’il émette un jugement négatif sur les fonctions de recherche de la plateforme. En effet, si on "torture" une base de données avec des questions complexes, c’est souvent parce qu’on n’a pas trouvé la réponse ailleurs et qu’on estime que le contenu de ma base est susceptible de produire des documents pertinents. Si alors elle ne permet pas de localiser ceux-ci, la plateforme ne remplit pas complètement son office et ne justifie que partiellement son prix
    • implémenter les opérateurs booléens, *tous* les opérateurs booléens. Pas seulement le ET (comme sur WK-RH), voire le ET et le OU (c’est insuffisant), mais aussi la troncature droite (* ou !), les expressions (" ") et les parenthèses. Et *surtout* la proximité (S/n). La proximité qui remplace avec profit, dans 8 cas sur 10, le ET trop souvent tapé. Sans troncature, expression, parenthèses ni proximité, si les résultats s’affichent par centaines et qu’on n’a pas de limite de date, il devient impossible de trouver dans un délai correct [6]
    • paramétrer très, très finement les moteurs de recherche sémantique (dits aussi "langage naturel" ou "Google-like") et/ou le classement des résultats par pertinence (qu’il s’appuie sur la sémantique ou simplement sur les termes utilisés dans la requête/question) et proposer en sus une version avancée du moteur fonctionnant en texte intégral classique avec opérateurs (cf point supra). En 2013, les tests effectués montrent que bien plus que la simple adoption d’un moteur sémantique, ce qui fait la pertinence réelle des résultats aux yeux du juriste expérimenté comme du documentaliste, c’est l’enrichissement du moteur sémantique par un thésaurus [7] (attention au coût et à la maintenance du thésaurus) ou au minimum un dictionnaire de synonymes [8] et/ou un paramétrage du classement des résultats donnant plus de poids au bon vieux critère de la présence du terme recherché ou de ses synonymes dans le titre du document ou du paragraphe, le chapeau ou encore l’abstract (cf la version de juillet 2013 de Dalloz.fr ou les améliorations apportées en 2012 à Lamyline [9]) [10]. Le moteur sémantique et sans opérateur peut aider grandement les utilisateurs [11], mais il peut se révéler trompeur ou incomplet [12]
    • le paramétrage de la liste des résultats. Ici, le tri par date et par pertinence (si celle-ci est réelle), la possibilité d’afficher ou pas des extraits semblent être les bases ...
    • la possibilité de constituer un "panier" contenant la liste des résultats sélectionnés, de le modifier, et de n’imprimer ou télécharger que ceux-ci
    • la mise en valeur ("highlight") des mots-clés de la question dans le document
    • afficher sous les zones de saisie ou à leur droite et en petits caractères, des exemples utilisant les opérateurs logiques de base (ET, OU) et éventuellement la proximité (S/n) et les parenthèses. Ce type d’aide brève et impossible à manquer se trouve chez Lamyline, LNJC et Legifrance
  • ne pas se contenter de mettre le contenu au format PDF, Word ou RTF, mais systématiquement doubler le document bureautique par une vraie page web. Plusieurs raisons à cela :
    • une page web/HTML se charge beaucoup plus vite qu’un document PDF, parce que :
      • le PDF oblige l’ordinateur à lancer Acrobat Reader qui est un "gros" logiciel et met donc beaucoup de temps à se charger [13]
      • les documents PDF, la plupart du temps, ne sont pas optimisés, i.e. allégés [14]. Ils "pèsent" en moyenne pas loin de dix fois plus en kilo-octets que leurs équivalents HTML : là encore, grosse perte de temps pour l’internaute
    • même si les grands moteurs de recherche indexent aujourd’hui les PDF de presque [15] toutes tailles, il demeure que :
      • le HTML leur est comparativement plus facile à indexer
      • surtout, même si les mots-clés situés profondément dans un fichier PDF sont indexés en théorie par Google, en pratique, un mot-clé situé à partir de la 10e page d’un PDF n’a plus aucune pertinence pour le moteur de recherche de Moutain View, sauf (et encore) s’il fait partie d’une expression cherchée comme telle avec les guillemets
    • enfin, le PDF est anti-pratique à lire à l’écran [16], il n’a même jamais été conçu pour ça, mais pour l’inverse : lire sur papier imprimé, off-line [17]
  • éviter au maximum les fenêtres "pop-up", même et surtout si c’est uniquement pour se connecter à la plateforme/site web (c’était le cas chez Navis). Dalloz.fr, lui, use et abuse des pop-up (même encore dans la refonte de la rentrée 2011), et même si les idées derrière sa conception peuvent expliquer ce choix, il n’est pas toujours optimal en pratique. En effet, les barres de moteurs de recherche ("toolbar") comme celles de Yahoo et Google, voire les paramètres des navigateurs web, peuvent bloquer les pop-up [18]. Chez les Yahoo et Google toolbars, ce bloquage est activé par défaut dès leur installation ! Or, seuls une minorité d’utilisateurs connaissent ce problème et encore moins savent comment le résoudre. Enfin, la multiplication des fenêtres pour une même base amènent l’internaute à "se perdre".

- l’accessibilité web : il s’agit de règles de lisibilité, principalement, destinées à favoriser l’accès aux sites par les personnes à handicap visuel. Voir pour un exemple la version de septembre 2011 de Legifrance. Ces règles sont définies par la recommandation du W3C, et les sites gouvernementaux ont l’obligation de s’y conformer. L’article 47 de la loi n° 2005-102 du 11 février 2005 pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées énonce en effet :

« Les services de communication publique en ligne des services de l’État, des collectivités territoriales et des établissements publics qui en dépendent doivent être accessibles aux personnes handicapées. »


Du fait du confort de lecture accru, des temps de chargement améliorés par un code HTML épuré et du meilleur repérage dans le site entraînés par le passage à cette norme, tout le monde en bénéficie, les voyants comme les mal voyants. Les éditeurs privés seraient donc bien inspirés de l’adopter.

- l’écran : même au meilleur standard actuel de 20 pouces et une résolution de 1280 x 1024, un écran d’ordinateur reste extrêmement limité par sa petite surface et son absence de 3ème dimension. D’où les règles de rédaction et de présentation établies par J. Nielsen : concis et aéré [19]. Ce qui suppose [20] :

  • un résumé ou à tout le moins un chapeau, chose qui, à part dans les articles de revues — et encore —, manque souvent à la littérature juridique française ou bien se révèle trop court
  • l’utilisation des "bullet lists" (listes à puces)
  • l’utilisation de liens hypertexte externes. Là encore, si les liens internes peuvent être là et si des citations/notes de bas de page vers des publications externes à l’éditeur seront souvent là [21], pour les liens externes entre plateformes d’éditeurs, on en est à la préhistoire
  • pour le reste, l’article de Comment ça marche sur l’egonomie fait très bien son travail d’évangélisation.

- Et bien sûr les publications imprimées traditionnelles — ici les ouvrages à mise à jour, traités et revues juridiques. Le bon vieux papier inspire encore, depuis le corbillard qui l’emmène si lentement [22] à sa tombe, une grande part des conventions de mise en page des pages web (le reste vient des grands sites web, cf supra) et dicte à 95% la mise en page des documents en ligne (je ne parle pas de la version imprimable, bien sûr) :

  • le document est écrit dans une police de caractères classique et lisible (Times New Roman, Arial, Georgia ou Verdana), en caractères noirs sur fond blanc cassé ou légèrement beige clair
  • un titre doit exister et être centré
  • l’auteur et ses qualités doivent être rappelés (à la fin du document et surtout au début de celui-ci)
  • il faut aérer la mise en page avec des sauts de ligne et des intertitres
  • le document, même non disponible en version pour impression, doit comporter toutes ses références de publication (titre, auteur, titre de la publication, directeurs de la publication le cas échéant, éditeur, ville et pays de l’éditeur si nécessaire, date de parution, rubrique, n° de page et de volume) en tête ou pied de page, comme s’il allait être imprimé. Qu’une version pour impression soit disponible ou pas, beaucoup de juristes internautes, pour aller plus vite, impriment les pages web telles quelles avec le bouton Imprimer du navigateur web. Si celles-ci ne sont pas bien mises en page ou ne comportent pas les références, c’est autant d’influence perdue pour le document et autant de facilité — et donc de popularité — en moins pour le produit.

Préférer les évolutions progressives

Les juristes dans leur très grande majorité ne sont pas des passionnés d’informatique et de technologies Internet (en anglais : "geeks") et encore moins des titulaires d’une formation de haut niveau en informatique. Par ailleurs, le milieu juridique français reste encore, malgré des évolutions, prudent et classique dans le choix de ses outils de recherche — comme l’illustre en bonne partie les « contraintes de facto » listées plus haut. Enfin, qui dit nouvelle version, grande migration ou mise à jour majeure dit risque important de "bug" non détecté.

Tout cela explique pourquoi les designers privilégient aujourd’hui, chaque fois que possible, les évolutions progressives par petites améliorations aux lancements de versions totalement nouvelles [23].

Avantages :

  • les utilisateurs ne sont pas déroutés et n’ont pas à réapprendre l’interface à chaque mise à jour majeure
  • peu ou pas de bugs
  • maintien de la confiance dans le produit [24].

Inconvénients :

  • les améliorations sont moins visibles
  • c’est également moins "marketing".

La liberté du concepteur

Pour autant, tester et servir les utilisateurs ne signifie pas qu’il faille en rester prisonnier. En effet, si on ne fait qu’écouter les utilisateurs, surtout les clients, ils ont tendance à être très conservateurs et en même temps à demander une multiplication de fonctionnalités dont beaucoup existent déjà sous une forme ou une autre [25].

Comme les deux premiers paragraphes de cet article le montrent et comme le soutient Don Norman (l’autre "N" du Nielsen Norman Group), les utilisateurs s’adaptent aussi aux interfaces et il vaut mieux centrer le développement des produits autour de l’activité que de l’utilisateur, ce qui selon Don Norman n’implique pas que l’on perde ainsi de vue les besoins de l’utilisateur [26].

La vision originale d’un éditeur n’est donc pas à remiser au garage dès qu’elle est inhabituelle. Dalloz a ainsi introduit avec sa plateforme en ligne une logique d’accès aux données juridiques en ligne très rigoureuse, très doctrinale, privilégiant l’accès par la source/publication ou par la matière et le renvoi d’un document citant à un autre cité à la recherche en texte intégral brute. Et malgré des excès (l’absence [initiale] de recherche sur l’ensemble des bases) ou des implémentations maladroites (le thésaurus), cette approche a séduit des juristes de haut niveau aussi bien que des étudiants de 5e année en stage professionnel. [mise à jour juin 23009 : En revanche, la lenteur de dalloz.fr ne "passe" pas.]

Le débuggage par les tests

Ne pas oublier de tester le produit :

  • tester loin en amont, avant la version finale : ce qu’on appelle en informatique les tests alpha (en interne) et béta (en externe). Ainsi que l’écrit Janice Redish de la firme de design web User Interface Engineering (UIE), « c’est bien mieux de découvrir les problèmes avec quelques utilisateurs lors d’un test d’utilisabilité [un beta-test, donc] que plus tard lorsque le design est sous les feux de la rampe et sous les yeux des clients. » (traduction par nos soins) [27]
  • tester *hors* des employés de la SSII et de l’éditeur (ils ne comptent pas : ce sont des utilisateurs experts et ils connaissent déjà bien le produit). Autrement dit : soit un panel de juristes professionnels (d’entreprise, avocats, notaires, magistrats), de documentalistes juridiques [28] et d’étudiants et enseignants en droit, soit des consommateurs et des juristes d’associations
  • tester simplement, si on manque de temps (ou d’argent) : comme l’explique J. Nielsen ou Carolyn Snyder (Paper Prototyping, 2001), il suffit de :
    • pour la lisibilité de la mise en page, le graphisme et l’emplacement des fonctionnalités, d’imprimer des pages couleurs et de les soumettre à cinq futurs utilisateurs [29]
    • faire tester en ligne pendant quelques heures à quinze (voire dix) à vingt personnes du public cible [30], en leur demandant de réaliser certaines actions types, comme une recherche déterminée, mais sans rien leur dire d’autre ni les aider en quoi que ce soit, juste en filmant et en notant leurs actions et propos. Un tel nombre de testeurs est insuffisant pour détecter tous les problèmes [31] mais cela peut en isoler de 35 à 70%, notamment les plus voyant et les plus gênant.

Pour tester, il faut posséder un site de développement (par opposition au site de production), sur une autre adresse que l’adresse publique, y envoyer une petite sélection d’utilisateurs aguerris et de débutants, analyser leur navigation et leur demander un "feedback" détaillé. Avantages : on ne sort en public que des fonctionnalités "blindées" qui marchent à coup sûr et les choix trop en avance sur leur temps peuvent tranquillement mûrir.

Une solution alternative, moins recommandable mais acceptable à la limite, consiste à garder en service pendant un an l’ancienne version du site/base de données. Quitte à insister lourdement auprès des clients sur ses limites et les avantages de la nouvelle version. Mais au moins, les utilisateurs fâchés avec les bugs et inconvénients ergonomiques de la nouvelle version pourront ils les éviter, le temps que les équipes de développement corrigent le tir.

En dehors des tests proprement dit, l’éditeur a également intérêt, tout au long de la vue du produit, à maintenir un dialogue régulier avec les utilisateurs. Les associations d’utilisateurs de documentation juridiques, telles que l’ADBS ou Juriconnexion, sont idéales pour cela, notamment grâce à des réunions tri- ou semestrielles avec leurs groupes de travail dédiés (Juriformation pour Juriconnexion, le groupe sectoriel Documentation juridique pour l’ADBS). Il est très efficace de faire venir à ces réunions les équipes de développeurs de l’éditeur ou celles du sous-traitant. Le minimum, c’est la présence du chef de projet, qui apporte des réponses techniques, et d’un responsable commercial de haut niveau, qui garantit par son implication que les choses avancent et que les souhaits des clients sont pris en compte.

Le contrôle qualité du contenu

En vrac :

  • exiger des auteurs copie ou lien de tout document cité (cf supra)
  • employer des "vérificateurs" qui vérifieraient que les citations sont correctes, que les liens hypertextes sont pertinents et détectent les absurdités/erreurs de raisonnement (si, si ça arrive)
  • recaler les paraphrases des arrêts, les quasi-recopies des communiqués de presse, les soi-disant commentaires qui n’apportent rien
  • aller chercher le débat et la contradiction (exemple des commentaires sur CJCE C-487/07 18 juin 2009 L’Oréal c/ Bellure : les meilleurs commentaires sont publiés au Legal SSRN et le meilleur débat sur le blog IPKat).

Communiquer sur la nouvelle version bien avant, mais aussi pendant et après la bascule

Il s’agit de communiquer sur les nouvelles fonctionnalités, la nouvelle mise en page, le nouveau design et la date de sortie et de répondre aux problèmes éventuels et questions suscitées par la nouvelle version.

S’il est certes nécessaire de ne pas s’engager sur une date de sortie tant qu’on n’en est pas certain à 100% [32], il est en revanche nécessaire pour les utilisateurs de se préparer à l’avance et donc pour les formateurs de les former.

Quels moyens employer ? :

  1. annoncer à un public — éventuellement sélectionné mais sans obligation de confidentialité — au moins trois mois à l’avance (idéalement six mois) qu’une nouvelle version se prépare, parler de manière très synthétique des grandes nouveautés et donner à un ou deux mois près la date de sortie (je ne parle pas ici des tests)
  2. puis diffuser des documents PDF avec des copies écran commentées — idéalement postés sur le site web de l’éditeur et annoncés par des e-mails à tous les clients. C’est un moyen facile et peu coûteux de prévenir tout le monde. Eviter de se cantonner à un mailing papier, qui sera lu uniquement — et encore — par les gestionnaires des abonnements
  3. des réunions organisées environ un mois avant la sortie avec les associations de documentalistes juridiques ou leurs groupes de travail, voire des groupes de clients représentatifs. L’avantage des associations, c’est qu’elles peuvent (mais ce n’est pas automatique) répercuter les informations dans une communication à l’ensemble de leurs membres ou les inviter à venir en nombre à la réunion
  4. enfin, le jour précédent la sortie, et le lendemain ou le surlendemain, des communiqués sur les forums et listes de discussion majeures utilisées par les utilisateurs (Village de la Justice) et les documentalistes juridiques (liste Juriconnexion et ADBS Documentation juridique).

Certains éditeurs ont toutefois manqué de magnifiques occasions de faire de la publicité pour leur produit en ligne en ne communiquant quasiment pas sur leur future nouvelle version.

Ne pas lancer la nouvelle version en pleine semaine de travail

Toujours basculer la nuit : cette règle d’or de l’informatique semble parfaitement respectée par les éditeurs. Pas toujours : on a parfois des mises à jour qui commance à 18h. Rappelons que les juristes français travaillent en général souvent tard.

Mais il faut ajouter qu’il est prudent de basculer vers une nouvelle version dans une nuit de samedi à dimanche [33], ou mieux pendant les vacances de Noël, entre le 25 décembre et le 1er janvier [34], ou au mois d’août. Si la bascule prend plus de temps que prévu ou "bugue", l’éditeur disposera alors de 24h ou mieux plusieurs jours, pour résoudre le problème, sans déranger outre mesure ses clients.

Emmanuel Barthe
documentaliste juridique, testeur de bases de données et plateformes juridiques en ligne

Notes de bas de page

[1Usability 101 : Introduction to Usability / Jakob Nielsen, Alertbox 25 août 20023. L’auteur, consultant en conception et design de sites web a beaucoup écrit sur le sujet. Voir aussi les articles Usability et Test utilisateur de l’encyclopédie contributive en ligne Wikipedia. Parmi les firmes et gourous de l’utilisabilité, on peut aussi citer Eric Schaffer (Human Factors International (HFI), le danois Rolf Moler (DialogDesign) et Jared Spool (User Interface Engineering (UIE).

[2Oui, le Lexis français première version de Lamy, tel qu’il existait en 1993 quand j’ai commencé à travailler.

[3En commençant par le premier succès de l’informatique juridique française sur cédérom, le cédérom Lamy Cassation.

[4Que la version en ligne d’une revue, d’un ouvrage soit constamment parfaitement à jour est une croyance, un mythe. Pas une réalité. Mais cette croyance crée une attente — et pour les 10% de réalistes une exigence — extrêmement forte qu’il vaut mieux éviter de décevoir.

[5Oui, les tables matières de revues, lorsqu’elles sont bien faites, sont précieuses. Or, avec le développement du numérique, elles tendent à disparaître.

[6Une bonne formation d’une heure — pas plus — aux opérateurs, la proximité devant venir en premier (voir nos billets De la nécessité pour les documentalistes juridiques de former eux-mêmes aux bases de données et Bases de données juridiques : pourquoi se former ?). Ne pas oublier aussi l’accès par point de droit et par les classiques table des matières et index/table alphabétique. Ces types d’accès sont consubstantiels au droit français et plus généralement romano-germanique et restent plus proches du raisonnement des juristes. aidera beaucoup les utilisateurs lorsqu’ils "pédalent dans la semoule". Les opérateurs logiques restent notamment incontournables en matière de veille automatique sur des requêtes complexes.

[7Seul Lexis 360 rentre dans cette catégorie.

[8Cas de Lamyline.fr (lancé en 2010) depuis 2011, notamment sur les suggestions du groupe Juriformation.

[9Améliorations qui ont notamment suivies les recommandations du groupe Juriformation.

[10L’enrichissement du document en mots-clés et synonymes est de plus en plus souvent invisible : c’est la cartouche sémantique Temis (avant le chargement du document) ou l’enrichissement de la requête par le moteur sémantique qui le fait. Il est dommage que les mot-clés ajoutés ne soient pas toujours visibles quand ils sont inscrits en dur (comme c’est le cas dans la base Juris-Data) ou les articles des revues sur Dalloz.fr) : voir ces mots-clés, voir pourquoi on trouve du pertinent a une vertu pédagogique.

[11Bon point pour Lexis360 et sinon la version de juillet 2013 de Dalloz.fr (sousExalead) s’approche du langage naturel par son classement par pertinence.

[12En matière de moteurs sémantiques et de classement des résultats par pertinence, les choses ont bien évolué depuis la période 2007-2011 et l’année 2013. Voici ce que j’écrivais entre 207 et 2011 : « Eviter les moteurs de recherche en langage naturel ou "Google-like" ou sinon, proposer en sus une version avancée du moteur fonctionnant en texte intégral classique avec opérateurs (cf point supra). Pour l’instant, les moteurs enrichis en thésaurus mis à part — pour l’instant, seul Lexis 360 rentre dans cette catégorie —, les expériences menées montrent qu’ils ne maîtrisent pas la langue juridique française (par exemple, des sigles comme SAS, de par leur ambigüité, ne peuvent pas déclencher la recherche automatique de leur développé, soit ici "société par actions simplifiée" ; ou bien, les résultats, passés les 10 premiers, sont bien moins pertinents ; ou bien encore, le premier résultat est bien moins pertinent que le 5e voire le 9e ...). Le moteur en langage naturel et sans opérateur peut aider les utilisateurs de base, mais il peut se révéler trompeur et ne vaut pas une bonne formation d’une heure — pas plus — aux opérateurs, la proximité devant venir en premier (voir nos billets De la nécessité pour les documentalistes juridiques de former eux-mêmes aux bases de données et Bases de données juridiques : pourquoi se former ?).

[13Les versions 6, 7 et 8 d’Acrobat Reader mettent, sur mon lieu de travail, plus de 30 secondes lorsqu’elles se chargent pour la première fois (une fois en mémoire cache, Acrobat ne met que 10 secondes à s’ouvrir).

[14Pour cela, produire le PDF avec Adobe Acrobat Writer — et non un logiciel "PDFiseur" gratuit —, directement à partir du document numérique — et non à partir d’un scan —, n’y inclure que quelques polices de caractère, en retirer les éléments inutilisés, et ré-enregistrer sous Acrobat. On retrouve ces conseils et d’autres dans les conseils d’optimisation des fichiers PDF donnés par Adobe (en anglais). On en trouvera d’autres — hélas dans un document PDF — sur le site web de l’Université d’Adélaïde (Australie).

[15Il semble que quelque part au-delà de 10 méga-octets, Google ne prenne pas du tout en compte un fichier PDF.

[16Faut il après toutes ces années ré-expliquer pourquoi le format PDF d’Acrobat, idéal pour l’impression et la lecture off-line, reste anti-pratique pour chercher et lire en ligne ? Pour les webmestres débutants, voici deux articles très concrets rédigés par un spécialiste peu contesté du design des interfaces professionnelles et commerciales en ligne, Jakob Nielsen : Avoid PDF for On-Screen Reading, Alertbox 10 juin 2001, PDF : Unfit for Human Consumption, Alertbox 14 juillet 2003.

[17Bien sûr, le format PDF a des avantages sur le HTML (PDF vs. HTML - A comparison of two file formats, 30 mai 2006), principalement en termes de respect de la mise en page et des polices de caractère à l’impression et de sécurité/DRM.

[18La raison de ce bloquage par défaut est la suivante : la plupart des pop-up sont des publicités — et souvent parmi les plus désagréables.

[19Oui, cet article de John Morkes et Jakob Nielsen pour Sun date de 1997, mais ses conclusions demeurent valables quatorze ans après. On peut aussi lire ces recommandations du site Good Documents et les articles du site de Jared Spool, User Interface Engineering (UIE). Jared Spool est le grand concurrent américain du Nielsen Norman Group, dont Jakob Nielsen est associé.

[20Attention, mettons nous bien d’accord : nous parlons ici de la version à lire à l’écran, *pas* de celle pour impression. Il est clair que sur la version pour impression, faire aéré et concis est nettement moins nécessaire. Tout simplement parce qu’on le la lira pas à l’cran et que de surcroît, si on imprime, ça veut dire qu’on a *choisi* ce document, qu’on le considère comme pertinent/intéressant et qu’on est donc prêt à y mettre plus de temps et d’attention.

[21Et encore : certain éditeur recommande à ses auteurs et surtout à ses secrétaires de rédaction de supprimer les citations externes dès qu’il en existe une équivalente chez l’éditeur.

[23C’est ainsi, et de manière particulièrement nette, le choix de Dalloz pour sa plateforme dalloz.fr.

[24C’est lors du passage à la V2 de Navis que Francis Lefebvre essuya une sévère "bronca" des utilisateurs fiscalistes. Nombreux furent les clients qui exigèrent — et obtinrent — de se voir maintenir la version précédente, avec les mises à jour du contenu. La situation dura plus de six mois. Pendant ce temps, l’éditeur dut maintenir, contre ses prévisions, deux versions de son produit en même temps, ce qui a dû représenter un coût non négligeable ...

[25Designing Web Applications for Use / Larry Constantine, 11 décembre 2006.

[26Human-Centered Design Considered Harmful / Donald Norman, Interactions (un magazine de l’Association for
Computing Machinery (ACM)) juillet 2005. Article à compléter par HCD harmful ? A Clarification. Un extrait pour mieux comprendre le propos de Don Norman : « Si je comprend bien la tâche, si je comprend vraiment le mélange de tâches qui ensemble représentent une activité et si je comprend réellement la manière mal conçue par laquelle la plupart des gens approchent leurs activités, alors je peux fournir une bien meilleure assistance que si je me focalise sur la formation, l’âge ou la personnalité des individus qui pourraient l’utiliser. » (traduction par nos soins)

[27Six Steps to Ensure a Successful Usability Test / Janice (Ginny) Redish, UIE 18 janvier 2005.

[28Notamment (publicité personnelle) les experts du groupe Juriformation, au sein de l’association Juriconnexion.

[29Ce que Jakob Nielsen appelle "paper prototypes". Cette limitation à 5 ou 8 testeurs a été conçue vers 1993 pour des logiciels fonctionnant sur un ordinateur, non pour les sites web. Elle fut toutefois considérée pendant pas mal d’années comme suffisante, notamment car elle limitait les budgets de tests. Lire Eight is Not Enough / Christine Perfetti, Lori Landesman, UIE 18 juin 2001 et Usability Myths Need Reality Checks / Will Schroeder, UIE 1er avril 2003. Voir l’article Test utilisateur sur Wikipedia pour plus de détails.

[30UIE évoque également la possibilité de faire tester chaque semaine un nouvel utilisateur. Sur six mois, cela fait 20 testeurs, avec l’avantage d’un test continu, au fur et à mesure des modifications du site.

[31Selon le spécialiste danois de l’utilisabilité et consultant Rolf Molich, le nombre de problèmes d’utilisabilité détectables a tendance à tendre vers l’infini. Sa série d’études CUE montre que plus le nombre de participants augmente et plus les techniques varient, plus le nombre de problèmes augmente lui aussi.

[32C’est malheureusement ce qu’a fait Francis Lefebvre fin 2008-début 2009 en annonçant le passage à la V3 de Navis pour le 23-26 décembre, puis pour le 15 janvier et en basculant enfin le 28 janvier, sans avoir prévenu quiconque parmi ses clients. Voir notre article Navis : la nouvelle version est lancée — Nombreux bugs, peu d’améliorations.

[33Ce qu’a fait LexisNexis pour sa version dite "2009" sortie à la rentrée 2008 : la bascule s’est faite dans a nuit du samedi 20 au dimanche 21 septembre 2008. Voir notre article LexisNexis-Jurisclasseur 2009 : premier bilan.

[34C’est ce qui était initialement prévu pour la V3 de Navis, la plateforme de Francis Lefebvre, mais des imperfections à régler ont reporté cela à la nuit du 27 au 28 janvier 2009, hélas en pleine semaine : voir notre article Navis : la nouvelle version est lancée — Nombreux bugs, peu d’améliorations.

Répondre à cet article

1 Message