Une roadmap user-centric pour les données sur l’eau

Le domaine était complexe et multi-acteurs — hydrologie, réglementation, données publiques. J'ai mené deux démarches en parallèle pour cadrer le problème.

Le cadrage avait posé une hypothèse : l'accès à l'information était le vrai frein. Restait à l'objectiver sur le terrain, à l'échelle réelle du site. J'ai mis en place une analyse comportementale par heatmaps, enregistrements de sessions et sondage de sortie (Hotjar), pour observer la navigation réelle sans mobiliser de recrutement ni de temps utilisateur : zones de clic, trajectoires de souris et perception déclarée à la sortie du site, trois angles croisés sur un volume de visites significatif. Les résultats confirmaient et précisaient l'hypothèse. 50 % des visiteurs de la page d'accueil quittent sans interagir et la rubrique la plus cliquée du menu est « Rechercher » (11,28 % des clics), signe d'une architecture de l'information qui ne correspond pas aux intentions des utilisateurs.  Sur la page de recherche avancée, 1 898 clics pour 965 vues, concentrés sur les filtres fins (station, commune, cours d'eau) : les filtres larges, eux, sont ignorés. 

Restait à mesurer combien d'utilisateurs étaient concernés par ces frictions, et à préciser leurs besoins réels, avant d'entrer dans les tests qualitatifs. J'ai conçu un questionnaire exploratoire auto-administré par mailing, pour quantifier les usages, besoins et frictions, ainsi que recruter dans le même temps les participants de la phase de tests suivante. Le public visé — 80 % administration publique et professionnels de l'eau — est dispersé géographiquement et difficile à observer en contexte. Le questionnaire l'atteignait sans contrainte de disponibilité.

L'architecture existante suivait la logique thématique de l'équipe projet. La question était simple : correspond-elle à celle des utilisateurs ? J'ai mis en place un tri par cartes ouvert en ligne, en format non modéré et sur un protocole court (10-15 min). Adapté à un public professionnel dispersé géographiquement, il a permis d'identifier les regroupements spontanés des utilisateurs.

Cette étape intervenait tôt dans le projet, avant que l'accès aux utilisateurs ne soit possible. Il fallait commencer à identifier et documenter les difficultés d'usage jamais formalisées. J'ai mené un audit heuristique par cas d'usage, une évaluation construite sur 7 parcours métier réels définis avec le client (collectivités, bureaux d'études, particuliers) pour ancrer l'analyse dans des situations concrètes plutôt que dans une revue générique de l'interface. 86 observations ont été classées sur 4 niveaux de sévérité, avec des blocages concentrés sur la navigation (fil d'Ariane absent, menus incohérents) et les téléchargements (contenu inaccessible sans action préalable). Le livrable a été structuré comme un backlog prêt à l'emploi, directement intégrable par le futur prestataire TMA. En complément, un audit de conformité Open Data par grille Opquast (72 critères) a croisé cet angle usages avec une vérification objective des standards de publication. 32 non-conformités ont été identifiées sur 48 critères pertinents, concentrées sur le catalogage, la licence et l'utilisabilité. Chaque écart a été livré avec une recommandation actionnable.

Le diagnostic (heatmaps, questionnaire) avait identifié les frictions ; le tri par cartes avait proposé une nouvelle structure. Il fallait vérifier que cette arborescence fonctionnait réellement pour les utilisateurs, avant tout développement. J'ai conduit des tests utilisateurs modérés à distance sur prototype, avec 5 participants du terrain, en combinant trois méthodes sur une même session : le test du premier clic pour mesurer l'instinct de navigation, le test d'arborescence pour valider libellés et structure hors interface, et un entretien de débriefing pour capter le contexte d'usage réel. Deux frictions majeures sont apparues : 80 % d'échec sur l'accès aux bulletins hydrologiques (les participants ne descendaient pas assez bas dans l'arborescence) et 60 % d'échec sur « Mesures territorialisées », un libellé mal compris. Le débriefing a apporté un signal plus structurant encore : 80 % des participants préfèrent une entrée cartographique par bassin versant pour les données de station — une priorité directe à intégrer dans le cahier des charges de la prochaine TMA. Les sessions ont aussi permis de formaliser 2 personas actionnables (profil « transversal données » et profil « thématique »), utilisés ensuite comme référence dans les arbitrages de conception.

Un dernier angle restait à couvrir : celui des équipes qui alimentent le SIE au quotidien. Côté back-office, les contributeurs utilisent le CMS Drupal, mais n'ont pas d'espace commun pour exprimer leurs frictions. J'ai animé un atelier de 3 heures à distance sur Miro, cumulant trois activités pour collecter et hiérarchiser les besoins : Speed Boat pour l'expression libre des blocages, Relais d'équipe pour l'enrichissement croisé des solutions, et une matrice importance/difficulté pour l'arbitrage collectif.