A propos de sites web

J'ai participé la semaine dernière à une assemblée générale d’une association Amicale des…

D’un côté quelques représentants du conseil d’administration, de l’autre côté quelques adhérents. Pas la foule, j’y reviendrai peut-être dans un autre billet, là je voudrais seulement commenter l’information découverte lors de cette assemblée : nous sommes en train de refaire notre site internet…

Bon, quand j’entends parler de site internet, j’oublie cette erreur de langage, il s’agit bien d’un site web, mais je voudrais revenir sur le nous sommes… 

Dans nous il y a moi et personnellement je n’étais pas au courant.

J’ai bien essayé lors de cette assemblée de poser quelques questions mais manifestement la cause était entendue et les décisions auraient déjà été prises et quelque part ça nous dépasserait puisque ce serait piloté à un niveau supérieur, notre association dépendant d’une fédération sur cet aspect.

Après ces quelques généralités énoncées pour essayer de planter un contexte, revenons aux principales informations entendues et qui m’ont fait réagir.

1. le site est en cours de mise au point, c’est donc normal qu’il y ait des bugs, d’ici quelques mois ça ira mieux !
2. c’est Mr X qui a en charge le sujet, d’ailleurs c’est lui qui administre tout seul, normal car quand il y a plusieurs personnes à gérer c’est le bazar !
3. ce nouveau site va tout faire, y compris gérer la liste des adhérents…
4. l’ancien site il faut l’oublier, maintenant il y a le nouveau.

Ce que je retiendrai de mes tentatives d’intervention, c’est que si projet il y a, nous pouvions être informés, est-ce que c’est X qui décide et formalise le CdC (cahier des charges) et est-ce lui qui fait la recette pour garantir le bon fonctionnement ?

Enfin, ce n’est pas le site qui gère la liste, là il est question de fonctionnalités couvertes par un projet qui peut être le même que celui du nouveau site mais il faudrait éviter de tout mélanger…

Il y a eu un échange sur des newsletters non reçues du fait d’un mauvais paramétrage des ordinateurs des destinataires et qu’il faudrait dialoguer avec X pour qu’il explique ce qu’il y a à faire sur les ordis, là j’ai cru rêver que justement le site ne propose pas une page en question voire un forum pour échanger sur les difficultés. Mais bon, quand on ignore la signification de FAQ ou PQSR (*), voire leur existence, on comprend que les fonctionnalités couvertes par ce genre d’applications ne figurent pas dans un CdC. 

Sans vouloir être exhaustif sur le comment conduire un tel projet, j’aimerai revoir quelques points à partir des 4 informations évoquées.

1) les bugs c’est normal, il faudra attendre quelques mois pour que ça passe : non, il n’est pas concevable d’ériger ce mode d’acceptation de la médiocrité. 

On ne met en production que des solutions éprouvées et quand on tombe sur un bug loupé lors des recettes on met en place un correctif rapidement afin d’éviter la routine (c’est normal que ça ne marche pas car c’est neuf).

Pour arriver à ce résultat il faut effectivement avoir un vrai projet donc avoir défini ce que nous voulions faire et mis en place la communication nécessaire avant, pendant et après la mise en production pour accompagner le changement et récupérer les informations ad hoc à chaque moment (les FAQ / PQSR peuvent être un canal performant pour échanger avec les adhérents).

Changer implique également un retour d’expérience sur l’ancien site : que faisait-il bien, mal ou ne faisait pas. Quels étaient les soucis ? Qui l’utilisait et comment ? On peut imaginer toutes les questions possibles à documenter au lieu de partir d’une page blanche, voire de reprendre telle quelle une autre solution développée pour on ne sait pas quoi faire (dans cette hypothèse l’essentiel du projet serait de bien communiquer pour faire accepter cette solution inacceptable…).

Même si on ne connaît rien, il faut quand même savoir dissocier le contenant du contenu, charge aux spécialistes de savoir adapter le contenu aux différents modes d’accès (téléphone, tablette ou ordi, ce qu'on appelle le responsive design) mais en aucun cas à ces spécialistes de définir le contenu. 

L’UX, l’expérience utilisateurs,  s’est développée ces dernières années et s’est outillée avec les méthodes d’analyses performantes. Là aussi il y a des spécialistes qui peuvent intervenir, mais bien souvent le bon sens utilisateur constitue un bon début, à condition d’aller chercher les utilisateurs. Tout seul dans son bureau ce n'est pas simple, encore moins si on n’a pas le temps. 

Personnellement j’ai toujours les mêmes exigences, trouver l’information qui m’est promise et avec un nombre de clics pour y parvenir limité (3 par exemple).

2) C’est X qui fait tout, pouvoir d’administration non partagé.

On nous explique quand même que si nécessaire il expliquera à quelqu’un d’autre comment faire…

Personnellement j’ai toujours anticipé les crises en répondant à la question si la personne en charge d’un activité ne se présente pas à son poste au moment prévu on fait comment ?

Les accidents ça arrive et de temps en temps ils sont mortels… Faire reposer un mode de gestion sur un seul accès  est suicidaire. Mais bon, c’est après le problème que peut-être les responsables s’en rendent compte.

Par ailleurs, si X fait tout, de l’expression de besoin jusqu’à la recette, il y a peu de chances qu’il réponde aux besoins des clients du projet. 

A l’occasion je vous invite à réfléchir quels sont ces clients (on pense tout de suite aux adhérents, mais les gestionnaires de l’association en sont d’autres ainsi que le ou les administrateurs de ou des applications). 

3) le site va tout faire : il y a une infinité d’actions possible, mettre à disposition de l’information et y accéder, gérer la liste des adhérents voire gérer le budget, lancer des campagnes de souscriptions ou d’adhésions, compter le nombre de visiteurs, localiser ces derniers, prendre l’avis des adhérents, prendre l’avis des visiteurs (c’est utile de savoir dissocier) etc. 

Liste à la Prévert qu’il conviendrait d’organiser et de hiérarchiser, ce n’est pas le propos de ce billet, le principal est de comprendre que sans faire ce travail préliminaire on passe à côté de l’essentiel. 

4) il faut oublier l’ancien site… Justement non, ce devrait être le point au départ de la réflexion, on change pourquoi ?

Parce que la précédente solution n’était pas pérenne et que le site allait devoir fermer (disparition du service par exemple), ça c’est incontestable et d’ailleurs ça peut figer les dates clés du projet, mis à part ce cas extrême on peut prendre le temps de travailler correctement et dans l’ordre. 

Faire un bilan des fonctionnalités couvertes, prévues et non prévues, de ce que les utilisateurs en font, de ce qu’ils auraient aimé pouvoir faire (on notera au passage que si on leur a toujours répondu pas possible sans même noter les besoins exprimés on ne pourra pas progresser), des choses qui « marchaient bien », il y en a toujours, sera toujours bénéfique avant l’établissement du CdC. 

Certes, avec les méthodes agiles, on simule tout de suite le nouveau site, les maquettes sont extraordinaires et époustouflantes… mais si on ne sait pas ce qu’on veut faire à quoi bon ? Changer pour changer n’est pas un objectif, on ne le dira / rappellera jamais assez.

Ces quelques remarques ont été formulées juste pour montrer que partir tête baissée sans regarder devant et derrière peut conduire dans une mauvaise direction. 

Définir le besoin et établir un plan d’actions pour parvenir à le satisfaire me semble un prérequis indispensable à toute refonte de site web.

En conclusion, même si on n’est pas expert d’un sujet, on a le droit d’être ouvert aux remarques voire de rechercher des contributeurs pour éventuellement avoir un plan de rattrapage si le projet est parti un peu de travers, mais ça ce serait le rôle d’un vrai manager : ne pas se substituer mais déléguer aux bonnes personnes.

Louis CHATEL le 18/03/2019 

D'autres billets sur le thème management ? Un petit tour sur l'Index de la catégorie "Management"  

(*) encore des acronymes, Foire Aux Questions et Pas de Question Sans Réponse, il faudrait que je mette à jour (MàJ) mon billet sur les acronymes...