Ebauche d’un code des bonnes pratiques des sites web publics

En finir avec les liens cassés, fils RSS et contenus supprimés ...

Mon collègue Rémy Lériginier (Faculté de droit de Poitiers) écrivait sur son compte Twitter (@rlerignier) :

« Chers webmasters de sites institutionnels qui supprimez ou modifiez les flux RSS sans préavis, je vous le dis comme je pense, vous m’em…nnuyez. Twitter, Facebook, Instagram… ne remplacent pas un ou des flux RSS »

Sur ce, Jean Gasnault (@LaLoiDesOurs) avait renchéri :

« Un code des bonnes pratiques des fils RSS publics serait le bienvenu. »

Si je peux ajouter ma pierre : au-delà des fils RSS, c’est un code des bonnes pratiques des *sites web* publics, plus généralement, qui serait le bienvenu.

Comme j’ai été webmestre [1] d’une institution publique pendant un an et quart — pendant lequel j’ai apporté ma part de petites améliorations — et que je suis redevenu utilisateur assidu des sites web publics, j’ai ma petite idée sur la question.

Soyons clair :

• primo, les bonnes pratiques ci-dessus, bien que proposées aux administrations, relèvent d’un consensus parmi les documentalistes et veilleurs. A l’exception des rencontres entre webmestres et avec les utilisateurs, elles constituent à notre avis un minimum
• secundo, elles sont dans l’intérêt bien compris aussi bien des citoyens contribuables que de l’administration et des juridictions, car elles amélioreraient considérablement l’expérience utilisateur ("user experience" ou UX, ex-usabilité [2]) et le référencement des sites publics, ce qui ne peut que bénéficier à la connaissance du droit et à l’application des réformes.

Voici donc une ébauche de ce que pourrait être un code des bonnes pratiques de webmastering et webdesign des sites publics.

Une partie de ces suggestions de bonnes pratiques découle indirectement des recommandations du Référentiel général d’amélioration de l’accessibilité (RGAA, ex-Référentiel général d’accessibilité pour les administrations). Chose intéressante : selon le site Design.numerique.gouv.fr, « toutes ces règles sont obligatoires ». Les recommandations du RGAA sont donc obligatoires pour les sites web des administrations. Toutefois en pratique, ce n’est pas aussi simple que ça. Le manque de budget, de connaissance du RGAA dans les administrations (sauf de haut niveau), ou les contraintes liées au CMS utilisés pèsent lourd.

Quelques uns des critères du RGAA

– Ne pas supprimer de contenu (communiqués et brèves d’actualité soi-disant périmés, documents anciens n’étant plus complètement à jour, bases de données difficiles à maintenir, anciens organigrammes ...). Notamment lors des refontes de site. Au pire, tout cela peut parfaitement être archivé/figé, sous forme de site statique ou de PDFs — voir pour un exemple l’Archive de la Base des décisions et informations financières (BDIF) mise en ligne par l’AMF (sur l’insistance des utilisateurs, et notamment de l’association Juriconnexion) — ce qui ne demande plus que très peu de maintenance.
Cela implique d’inclure systématiquement dans les cahiers des charges de refonte de site la reprise ou l’archivage en ligne des documents et bases anciens.

– Eviter de mettre hors ligne les bases de données importantes ou complexes à chaque refonte de site. Exemple : la base Traités et accords de la France, depuis sa mise en ligne sur le Web, a déjà été trois fois victime de ce traitement. Ce serait un grand progrès pour l’e-administration et pour la diffusion et la défense du droit français que de maintenir cette base sans régulièrement la mettre hors ligne.

– Toute nouvelle publication, communiqué ou information doit être répercutée dans un fil RSS — et non uniquement sur Facebook, Twitter ou autre réseau social (ça plaît beaucoup aux chargés de communication, mais ce n’est pas pratique pour la veille). Si possible également par email.
Les fils RSS doivent être structurés ainsi :

• un fil général, reprenant tout
• un fil par rubrique du site
• si possible, un fil par thème.

– La mise en page des impressions des pages web doit être propre et ne perdre aucune information — plutôt que de fournir une version PDF systématique, ce qui fait perdre du temps au webmestre ou à l’auteur du document

– Toute page web doit être "mobile friendly" (on parle de RWD) pour les smartphones et tablettes (écrans de taille réduite).

– Corrélativement, éviter absolument de créer des applications iOS ou Android. Elles font plaisir à la hiérarchie et aux communicants [3]. Mais :

• en pratique, ces solutions sont incapables de reprendre tout le contenu du site
• elles sont infernales à mettre à jour. Elles aboutissent en fait à ce qu’il y ait deux sites web différents à gérer et non plus un seul
• enfin, elles sont infiniment plus coûteuses qu’un site aux pages adaptées pour les mobiles.

– Maintenir les URL (adresses web) des liens anciens lors des nouvelles versions des sites [4] ou mettre des redirections automatiques en place. NB : c’est là un truc de référenceur (SEO) et cela bénéficierait à l’audience des sites publics.

– Aucun document ne doit être proposé que et seulement que en version téléchargeable mais toujours au minimum en version page web. Cela, notamment, améliore le référencement mais aussi la lisibilité pour les handicapés visuels.

– Les grands tableaux et documents longs (plus de quelques pages), peu pratiques à visualiser sur une page web, sont à proposer également en version téléchargeable dans un format open source (PDF, Open Document Format etc.).

– Les services de l’institution (pas forcément le webmestre lui-même) répondent sous 24h — le jour même ou le jour ouvrable suivant — aux questions posées à l’adresse de contact ou par le formulaire du site. Si la question est complexe, ils indiquent un délai raisonnable — une à deux semaines semble un maximum. Je me souviens ainsi d’un cas où le Sénat me répondit dès le lendemain mais pas l’Assemblée nationale. De nos jours, peu de citoyens ou d’entreprises ont le luxe de pouvoir attendre 48h+ une réponse à une question simple ...
Ce délai inclut les informations sur les pannes et bugs — mais aussi les refontes — du site web de l’institution et les arrêts d’alimentation de leurs bases de données.

– Les webmestres doivent parler avec quelques uns de leurs utilisateurs pour avoir des retours sur le site. S’il y a un gros problème, il remontera tout seul.
Idéalement, les webmestres devraient consulter régulièrement — une fois par an par exemple — les communautés utilisant le site web de leur institution. Cela pourrait prendre pour forme des réunions ad hoc d’utilisateurs, des questions ou invitations à feedback sur des listes de discussions ou forums modérés etc.

– Les webmestres des sites publics d’institutions similaires devraient communiquer entre eux — avec l’aval de leur hiérarchie et en la tenant au courant de leurs discussions — sur leurs problématiques communes (marchés publics de web design, d’hébergement et d’assistance, CMS utilisés ou recommandés ...).

– Les liens vers les pages correspondantes de data.gouv.fr où télécharger les données publiques de l’institution doivent être listés, rappelés chaque fois que c’est utile et mis en avant (par exemple en lien systématique de bas de page, dit footer) [5]. C’est en fait une application de la loi Lemaire République numérique : en application de l’article L 322-6 du Code des relations entre le public et l’administration (CRPA), les administrations qui « produisent ou détiennent des informations publiques tiennent à la disposition des usagers un répertoire des principaux documents dans lesquels ces informations figurent ». C’est ce qu’on appelait les "répertoires d’informations publiques" (RIP). La DILA et Bercy sont parmi les rares administrations à tenir un RIP. La DILA répertorie dans le sien *tous* les jeux de données qu’elle rend disponible, comme les simulateurs ou les guides, et pas seulement les bases de données juridiques diffusées sur data.gouv.fr.

Le RIP de la DILA

– Les vidéos doivent être postées/hébergées soit sur le site même de l’institution, soit sur Dailymotion soit sur Vimeo — la Cour de cassation héberge les siennes sur Vimeo — soit encore sur une instance Peertube. Ce, afin d’être cohérent avec le discours officiel de souveraineté numérique et surtout afin d’éviter la collecte de données personnelles à laquelle procède massivement YouTube (filiale de Google). Concrètement, ne pas faire ce qu’a fait la DGFiP pour expliquer le prélèvement à la source : héberger une vidéo sur YouTube, à regarder quasi-obligatoirement pour pouvoir remplir sa déclaration de revenus (la procédure pour l’éviter est fournie par Numerama ou la DGFiP elle-même).

Une des vidéos des colloques de la Cour de cassation hébergées sur Vimeo

Enfin, on peut ajouter à ces bonnes pratiques une partie importante de celles que j’ai déjà données pour les bases de données des éditeurs juridiques [6].

Emmanuel Barthe
documentaliste juridique, ex-webmestre des sites Internet et intranet de la Cour de cassation