Est-ce que uMap a besoin d’une designer ?

18 juillet 2026

Le projet uMapest libre, porté par une communauté et utilisé sur de nombreuses instances.

Avec plus de 190 000 comptes créés et une croissance continue depuis sa création, une question peut se poser : est-ce que uMap a vraiment besoin d’une designer ?

Nous avons fait l’hypothèse que oui 🙂. Parce qu’à plusieurs on est plus fort et aussi car à l’écoute des contributions de toutes sortes Yohan a déjà identifié une partie des points de souffrance ou ma participation serait la bienvenue .

Objectifs de la mission :

Améliorer l’ergonomie pour rendre uMap plus simple à prendre en main
Designer des fonctionnalités utiles
Ouvrir une instance dédiée aux agents publics
Faciliter l’adoption des personnes peu techniques ou débutantes

1- Premier pas

Pour s’immerger dans le projet, nous croisons 3 sources :

L’expérience de Yohan
Les retours de la communauté (GitHub, forum OSM…)
des entretiens avec des agents publics

Mon travail de designer consiste à capitaliser, organiser et rendre découvrable cette matière pour repérer les usages, les problèmes récurrents, les relier à des situations concrêtes et identifier les sujets prioritaires.

2- “Une mauvaise expérience utilisateur résulte systématiquement d’une équipe de design mal informée” J. M.Spool

Cette phrase de J.M. Spool me revient souvent en tête et justement un des principaux challenges au début de la mission était d’acquérir un maximum d’informations et de connaissances sur le produit et son écosystème.

Yohan nous a faciliter le travail grâce à des échanges, des démos ou encore des synthèses détaillées décrivant les problèmes connus et les retours de la communauté.

Pour avancer sur les sujets, j’alternais des sessions de tests, de recherche, de design et de remue méninges en équipe.

3- Range ta chambre d’abord !

Ou comment faciliter l’utilisation et la compréhension d’uMap

Une des activités principales du designer est de “Ranger, trier, étiqueter” en appliquant les principes d’ergonomie UX et en se basant sur les parcours et les retours des utilisateurs et utilisatrices

Ranger les informations
Regrouper ce qui va ensemble
Donner des noms cohérents
Rendre le fonctionnement du produit plus facile à comprendre

3-1 Premier exemple : simplifier la navigation interne

L’un des premiers “gros sujets” concernait les panneaux de navigation. Beaucoup d’utilisateurs avaient du mal à s’y retrouver.

Résultat du rémue-méninges :

Passage de 5 à 2 panneaux
Déplacement de certains panneaux pour les regrouper par usage
Possibilité de réduire leur hauteur pour laisser plus de place à la carte

Pourquoi est-ce que ces changements permettent de répondre au problème ?

uMap propose une même interface pour consulter et modifier une carte. En consulation les outils sont affichés sur fond blanc. En édition, de nouveaux outils apparaissent sur fond gris foncé. Certains panneaux de consultation se trouvaient avec les outils d’édition.

Nous avons donc ranger :

Les outils de consultation à gauche, sur fond blanc
Les outils d’édition à droite sur fond gris.

Nous avons aussi fusionné plusieurs panneaux qui remplissaient des fonctions proches. Finalement, la navigation est passée de 5 blocs distincts à 2 :

Navigation (calques, données, facettes)
À propos (titre, description, crédits)

3-2 Deuxième exemple : les niveaux hiérarchiques

Les retours des utilisateurs étaient :

Quand je veux modifier la couleur d’un élément je ne sais pas forcément ou je dois aller, il faut alors me documenter pour comprendre comment ça marche puis inspecter les panneaux propriétés des différents niveaux.

Je vois ma liste de calques : je me demande qui est quoi ? (Chloropleth, cluster, … ?) je suis obligé de masquer les calques pour m’y retrouver. Lui il est en rouge et en cluster ?

Yohan avait alors en tête que l’arrivée sur uMap d’un niveau hiérarchique supplémentaire : le groupe de calques, allait surement accentuer le problème.

Dans uMap la logique de hiérarchie est la suivante : Une propriété peut-être définie à plusieurs niveaux (carte, calque ou élément), et c’est toujours le niveau le plus précis qui l’emporte.

ément > Calque > Carte

Par exemple :

la carte définit une couleur bleur
le calque une couleur jaune
l’élement une couleur rose

La règle est simple et l’objectif est plutôt de la rendre visible.

J'ai commencé par mettre à plat l’existant et… ranger 🙂

Identifier les propriétés propres à chaque niveau
Uniformiser ou clarifier le vocabulaire
Rendre la hiérarchie plus visible
Grouper les propriétés impactées par l’héritage d’un côté et les propriétés spécifiques à un niveau de l’autre.

L’objectif n’était pas de changer le fonctionnement mais de le rendre plus visible.

J’ai également explorer 2 pistes pour rendre visible l’héritage :

1- L’ajout d’un bouton Hiérarchie dans le menu contextuel lié à un objet de la carte
2- L’ajout de l’information concernant le niveau au s’applique la propriété de l’objet
3- une zone pour identifier ou l’on se trouve dans la hiérarchie

4- C’est quoi le problème ?

Avant de chercher une solution, il faut être sûr de résoudre le bon problème. C’est un mantra que l’on entend souvent dans la conception numérique.

Ici le sujet portait sur le choix des fonds de carte.

Le problème était : il n’est pas facile de retrouver les 2 ou 3 fonds de carte que l’on utilise régulièrement. La liste comptait 39 fonds de carte, dont plusieurs très proches les uns des autres.

Nos premiers échanges ont porté sur la conception d’un nouveau fonctionnement permettant :

de prévisualiser les fonds de carte
Choisir les fonds de carte à mettre à disposition
Sélectionner le fond de carte par défaut

Et puis, dans le contexte de l’instance agents publics, nous avons pris un peu de recul.

Le problème alors n’était peut-être pas l’interface, mais le nombre de choix.

Nous avons donc reformulé la question :

Et si la liste était simplement plus courte ?

L’idée est alors devenue de regarder quels fonds de carte étaient réellement utilisés et de limiter la sélection à une dizaine sur certaines instances, notamment celle destinée aux agents publics.

Si la liste devient suffisamment courte, il n’est plus nécessaire d’ajouter un moteur de recherche, un système de favoris ou un écran de configuration supplémentaire.

C’est à ce moment-là que Yohan a lancé cette phrase que j’avais noté à l’époque :

« ah mais en fait ce que tu dis c’est qu’on aurait même pas besoin de designer / dev cette fonctionnalité si on a une liste plus courte !”

Prendre le temps de mettre à plat, reformuler le problème en équipe peut parfois éviter plusieurs jours de design et de développement.

5- Mettre en place un système de design

Une fois qu’on a mis de l’ordre 🙂 on peut le documenter pour qu’il dure dans le temps.

Voilà une recommandation simple : mettez en place un design system.

Quand plusieurs personnes font évoluer un même produit avoir un langage design commun est important 🙂

Et un design system permet de ne plus se poser la même question à chaque nouvelle interface : quel bouton utiliser ? Quelle couleur ? Quel espacement ? Quelle icône ?

L’équipe gagne du temps, le produit est plus cohérent et les utilisateurs retrouvent plus facilement leurs repères.

C’est ce que nous avons progressivement construit pour uMap : https://dev.umap-project.org/design_system/

6- Ecouter et observer les gens

uMap évolue grâce à la communauté.

Les retours arrivent de plusieurs sources :

issues sur github
forum OpenStreetMap
messages nternes
échanges lors d’évènements, webinaires oudes visio ouvertes

Mais une partie des personnes utilisatrices sont hors radar, elles n’écrivent pas messages. Elles utilisent uMap, ou aimeraient pourvoir l’utiliser sans forcément participer aux discussions.
D’autre part une conversation permet d’aller chercher des réponses plus précises à des besoins identifiés.

Notre mission est donc d’aller les rencontrer. Nous avons organisé des échanges et des tests avec des utilisateurs et utilisatrices réelles ou potentielles.

Objectif : Faciliter l’adoption et l’utilisation d’uMap pour des publics non techniques, débutant.es ou des personnes n’ayant encore jamais osé faire une carte sur uMap

Les questions génériques sont simples :
1- Est-ce que la personne a atteint son but ?
2- Est-ce que le produit est galère à utiliser ?
3- Est-ce que la personne revient ? recommande uMap ?

Très vite, on a constaté que pour les personnes moins techniques ou moins bidouilleuses, les premiers pas sur uMap sont souvent difficiles.

Leurs usages sont variés :

cartographier des défibrillateurs ou des travaux ;
créer des cartes pour des événements (concerts, fête de la musique, parcours) ;
localiser des lieux culturels, sportifs ou touristiques ;
représenter des îlots de fraîcheur ;
suivre des incendies ou des feux de forêt ;
partager des données en interne ;
produire des cartes collaboratives (écoles, rues, genres, etc.).

Ces besoins montrent des contextes très différents ou les premiers pas sont souvent un point de friction commun. Observer, écouter, tester, c’est ce qui permet de comprendre ces usages et guider la conception.

Les échanges avec les utilisateurs et utilisatrices sont un des éléments les plus importants du projet. Ils orientent directement les choix de design et de priorisation.

7- Comment les décisions sont-elles prises ?

En rejoignant une équipe aux compétences spécifiques et complémentaires sur uMap, une nouvelle question est apparue : Comment sont prises les décisions ?

Nous avons pris le temps lors d’un séminaire d’équipe de partager nos questions et de prendre des décisions pour nous améliorer : )
uMap fonctionnait jusque-là de manière assez organique. Yohan forcément très impliqué dans le projet centralisait les retours de la communauté et pouvait proposer des évolutions via des pull requests.

Avec l’arrivée d’une bande à ses côtés, nous avons décider de garder une organisation légère, mais plus structurée. On a mis en place un point régulier, après chaque release, pour discuter des évolutions à venir et décider ensemble des priorités.

Ce travail de priorisation repose sur un effort continu : lire les retours utilisateurs, les relier entre eux et les transformer en sujets concrets. Prendre part à la gouvernance ça veut dire aussi pouvoir s’impliquer davantage.

8- Accessibilité

Les cartes numériques ne sont pas soumises aux mêmes obligations d’accessibilité que d’autres types de produits.

Sur uMap, plusieurs pistes permettent d’améliorer l’accessiblilité.
Nous avons commencé par travailler sur les pages satellites et exploré différents manières de tester et comprendre les usages.

Pour tester, vous pouvez :

naviguer au clavier, avec une seule main si vous aimez être challengé·e
ou à la voix si vous êtes aventureuxse
vérifier le contraste suffisant de votre produit, à l’œil ou avec un outil gratuit
vérifier que votre contenu est dans le bon ordre en désactivant toutes les feuilles de styles
surfer avec un lecteur d’écran (donc une synthèse vocale), autre aventure
découvrir les fonctions d’accessibilité de votre système d’exploitation : touches rémanentes, mode haut contraste, filtre monochrome, réduire les animations, inverser les couleurs… et consulter votre produit
(Merci à Erwan le Gall pour cette liste )

Dans le cadre d’une nouvelle mission commencée en avril dernier je vais pouvoir continuer à explorer ce sujet, notamment autour des fonds de carte plus accessibles.

Conclusion

J’espère que ce retour d’expérience vous aura intéressé 🙂

Pour conclure je retiens d’uMap sa temporalité particulière. Un projet qui se déploie dans le temps, qui évolue de manière organique et continue sa vie même quand l’équipe est réduite ou que le principal contributeur fait le tour du monde en péniche.

De mon côté je suis heureuse de pouvoir continuer à y contribuer.

Au delà du produit, uMap permet de mesurer comme pour d’autres communs, la valeur de ces projets collectifs : des espaces ou se créent de la coopération, de la solidarité, de l’apprentissage sur le long terme. Et ça, ça n’a pas de prix.

Travailler sur uMap m’a permis de participer à ce projet avec bonheur tout en partageant un bout de chemin avec des personnes riches et inspirantes. Spéciale dédicace à Yohan, David, Alexis, Virgile, Ariane et Sophie 🙂