Kentyou
DATE
2025
PLATEFORME
SaaS B2B
MON RÔLE
Product Designer
DATE
2025
PLATEFORME
SaaS B2B
MON RÔLE
Product Designer
Aide à la décision climatique pour l'aménagement urbain. Une plateforme, trois utilisateurs très différents.
PLATEFORME
SaaS B2B
DATE
2025
Le client a demandé de garder ce projet discret et de ne pas montrer l'interface : tout est donc volontairement anonymisé. Cette étude de cas vend la réflexion, pas les pixels.
J'ai standardisé la façon dont une métropole française suit et simule la chaleur urbaine, sur la plateforme en marque blanche que je conçois pour Kentyou depuis 2021, validée en test et aujourd'hui en développement pour trois utilisateurs aux besoins opposés.
CLIENT
Kentyou est une entreprise spécialisée dans les solutions innovantes pour les villes intelligentes. Elle développe Kentyou Eye, une plateforme web en marque blanche adaptée aux besoins de chaque organisation, qu'il s'agisse de collectivités ou d'entreprises privées, pour les aider à suivre leurs données et leurs indicateurs clés. Je collabore avec Kentyou depuis 2021 sur plusieurs projets construits sur cette plateforme, et ce projet climatique de 2025 est l'un des plus récents.
CONTEXTE
Les villes se réchauffent, et les zones urbaines denses piègent cette chaleur bien plus que la campagne qui les entoure. Ce projet a été conçu pour aider une métropole française à comprendre ce problème sur son propre territoire : suivre des indicateurs climatiques, simuler comment un nouvel aménagement va les faire évoluer, et s'en servir pour prendre de meilleures décisions d'urbanisme. Il s'inscrivait dans une initiative climatique européenne, menée par un consortium de quatre partenaires, où j'étais la seule designer côté Kentyou.
LES UTILISATEURS ET LEURS FRUSTRATIONS
Le plus difficile, sur ce type de projet, ce n'est pas de rendre les écrans beaux. C'est de partir d'une même plateforme et de l'adapter à chaque mairie, à chaque client privé : récupérer leurs besoins, leurs frustrations, leur process de travail et leurs objectifs, pour proposer une solution qui les aide vraiment au quotidien, sans repartir de zéro à chaque fois.
Sur ce projet climatique, cette contrainte a pris une forme précise : trois personnes complètement différentes devaient travailler à partir de la même plateforme et des mêmes données climatiques, pour des raisons opposées et à des échelles opposées.
CHARGÉ D'ÉVALUATION
Évalue un seul aménagement, suit son impact sur un cycle de vie de 10 à 15 ans, et doit expliquer les résultats aux élus.
CHARGÉ DE SIMULATION
Lance des simulations fines, teste comment l'ajout ou le retrait d'arbres modifie la chaleur locale, en autonomie, sans équipe de modélisation.
DIRECTEUR
Pense le territoire entier à l'horizon 2040 et 2050, et ne veut que des tendances agrégées et des rapports de haut niveau.
À cela s'ajoutent trois contraintes. Les données sont lourdes et scientifiques (indices d'îlot de chaleur, confort thermique, densité de canopée, stockage du carbone), mais un non-expert doit pouvoir les lire. La plateforme est en marque blanche, donc tout ce que je concevais devait s'adapter à ce projet sans casser le socle commun utilisé par d'autres clients. Et l'expérience devait passer d'une carte 2D à un outil de simulation 3D distinct sans que l'utilisateur ne perde le fil.
J'ai rejoint ce projet une fois la phase de recherche initiale déjà bien avancée : cinq entretiens avec les parties prenantes, trois personas et les premiers parcours utilisateurs étaient déjà faits. J'ai absorbé ce travail, clarifié le vocabulaire métier, et l'ai transformé en un backlog priorisé d'une quarantaine de user stories réparties sur les trois vues, étiquetées par persona et par priorité, ce qui m'a permis de remettre en question quelques hypothèses avec le client très tôt (édition de rapport, couches de données, création des scénarios) avant qu'elles ne deviennent des écrans coûteux. À partir de là, j'ai porté le design de bout en bout : wireframes, parcours utilisateurs, UI haute-fidélité sur le socle Kentyou Eye, tests d'utilisabilité et handoff aux développeurs.
Cette plateforme, je la connaissais déjà bien : je l'avais testée avec de vrais utilisateurs sur d'autres déploiements, pour d'autres collectivités et d'autres sujets, la vue projet y était différente, mais les fondations UX étaient les mêmes.
Collaboration et équipe : je travaillais comme prestataire pour Kentyou, sans contact direct avec la mairie cliente. Le lead dev était présent à chaque réunion ; la validation venait du lead dev, du product owner et du founder de Kentyou à chaque jalon.
Un socle unique plutôt que trois produits.
J'avais trois personas tirant dans des directions opposées. Plutôt que de construire trois produits, j'ai donné à la plateforme une colonne vertébrale unique : une liste de projets, une vue détail d'un projet organisée par phases, une vue carte 2D et un accès vers la simulation 3D. Ce qui change d'un persona à l'autre, c'est le point d'entrée et la mise en avant, pas la structure. Le chargé d'évaluation entre par les projets, le chargé de simulation par un thème ou une zone géographique, le directeur par les indicateurs à l'échelle du territoire. Mêmes briques, agencées autour de ce que chaque personne cherche réellement à faire. Cela a gardé le produit apprenable, et compatible avec le socle en marque blanche.
La fonctionnalité qui a suscité la plus forte réaction en test.
Les projets urbains s'étalent ici sur 10 à 15 ans, et les indicateurs n'étaient pas cohérents d'un projet à l'autre, ce qui rendait l'impact difficile à suivre. J'ai traité chaque projet comme une série d'états (initial, phases définies, perspective prospective) avec la même mise en page et les mêmes métriques à chaque fois. Cette standardisation a rendu possible une comparaison état initial / état final, la fonctionnalité qui a reçu les retours les plus positifs, aussi bien en test qu'en revue avec les parties prenantes, parce qu'elle répond à la question que tous les utilisateurs se posaient vraiment : ce projet va-t-il réellement améliorer les choses ?
La lisibilité en surface, la profondeur à un clic.
Les indicateurs climatiques sont calculés à partir de données satellites et de machine learning : crédibles, mais denses. Je les ai conçus comme des couches activables sur la carte, avec des statistiques standardisées par zone et par phase, pour qu'un même indicateur serve à la fois un technicien et un élu. L'arbitrage permanent était profondeur contre lisibilité, et j'ai toujours choisi la lisibilité en surface, avec la profondeur à un clic.
Ma première version de l'écran de présentation des projets n'a pas tenu la route. La création des user flows a pris plus de temps que prévu : ce que voulait le founder, ce que demandaient les utilisateurs et ce que l'équipe tech comprenait n'étaient pas alignés, en particulier sur la façon dont les versions d'un projet devaient être représentées et créées. Je l'ai repris plusieurs fois avant d'aboutir à quelque chose qui tienne pour tout le monde.
Sur ce projet climatique, j'ai mené un test d'utilisabilité sur un prototype haute-fidélité cliquable avec un utilisateur réel côté ville, en parcourant les trois vues principales : dashboard, projet et carte. La comparaison état initial / état final (voir « Décisions clés ») y a reçu les retours les plus positifs de tout l'outil. Les autres retours (sur le paramétrage des valeurs cibles, la gestion de plusieurs états futurs par projet, ou les zones personnalisées sur la carte) ont directement nourri la roadmap détaillée dans « Prochaines étapes ».
Ce test n'a couvert qu'un seul utilisateur, mais s'appuie sur une méthode que je maîtrisais déjà : j'ai testé cette même plateforme avec des utilisateurs sur d'autres projets, pour d'autres collectivités.
Je pousserais pour un second testeur avant la validation finale. Un seul utilisateur réel a confirmé que la fonctionnalité de comparaison centrale fonctionnait, mais le reste des retours (valeurs cibles, plusieurs états futurs, zones personnalisées) repose encore sur un seul point de vue.