DM
UX / UI Design Data Platform · B2B ENGIE POC · 2026

ENGIE Data
Marketplace

Conception d'une marketplace de données interne pour le Group Chief Data Officer d'ENGIE, permettant à toutes les entités du Groupe de découvrir, comprendre et consommer des data products certifiés — avec ou sans expertise technique préalable.

Rôle
Lead Designer
UX & UI
Équipe
1 PO · 1 PM
1 dev front · 1 dev back · 1 DevOps
Format
Appel d'offre
POC 2 semaines
Timeline
Janvier →
Avril 2026
Outils
Figma · Figma Make
ENGIE Fluid DS
01
Problème

Un besoin sans précédent,
une solution interne qui avait déjà échoué.

Le contexte de départ

ENGIE souhaitait permettre à ses entités de partager et consommer des data products à l'échelle du Groupe — données de batteries de stockage, dispatch électrique, positionnement d'éoliennes, inventaire d'assets. Aucune solution du marché (Databricks, AWS, Snowflake) ne répondait précisément à ce besoin, d'où un appel d'offre ouvert.

Un précédent projet interne, le CommonDataHub, avait échoué faute d'adoption : conçu par des ingénieurs pour des profils techniques, sans designer, il était perçu comme trop complexe par les utilisateurs finaux. La principale injonction du commanditaire était de ne pas reproduire ce travers. Défi supplémentaire : la notion même de "data product" n'était pas encore stabilisée en interne — les équipes ne partageaient pas de référentiel commun pour la définir.

02
Démarche

Centrer sur l'utilisateur malgré
un brief incomplet et 2 semaines.

Triangulation de 3 sources

Le brief initial était largement insuffisant pour concevoir un produit solide. J'ai fait le choix de l'élargir pour recentrer le travail sur les utilisateurs finaux — et non sur les seules attentes des commanditaires — ce qui, dans une culture top-down, représentait un parti pris fort. Sans accès direct aux futurs utilisateurs de la marketplace, j'ai triangulé trois sources complémentaires.

Recherche indirecte
Entretiens CommonDataHub
Interviews d'utilisateurs de l'ancienne solution pour extrapoler frictions et besoins vers le nouveau produit.
Benchmark
Analyse des références marché
Snowflake, Databricks, AWS Marketplace — patterns communs, écueils et décisions de simplification à reprendre.
Exploration accélérée
Figma Make pour les wireframes
Génération de wireframes exploratoires à partir du benchmark, compressant le cycle exploration → décision → maquette.
03
Insights

Ce que la recherche
a révélé.

Frictions identifiées

Friction terrain
Complexité perçue comme frein à l'entrée
L'ancienne interface était conçue pour des profils techniques. Même les utilisateurs initiés rencontraient des difficultés, et la courbe d'apprentissage était citée comme premier obstacle à l'adoption.
Friction terrain
Recherche et filtrage défaillants
Difficile d'affiner une recherche ou de découvrir des datasets pertinents — une fonctionnalité pourtant centrale dans une marketplace.
Insight benchmark
La densité nuit à la lisibilité
Les solutions existantes présentent des fiches produit surchargées, sans hiérarchie visuelle claire. Résultat : charge cognitive élevée et taux d'abandon important à l'entrée dans une fiche.
04
Utilisateurs

Quatre profils,
deux priorités assumées.

Périmètre de ce POC

E
L'Explorateur
Découvre la marketplace
« Je ne sais pas si cette donnée est fiable ou pertinente pour mon cas. »
Priorité POC
C
Le Consommateur
Consomme des data products
« C'est intéressant, mais je ne sais pas comment l'intégrer à mon environnement. »
Priorité POC
P
Le Producteur
Publie des données
« Publier mes données est trop complexe. »
Hors périmètre
D
Le Développeur
Intègre via API
« L'API est mal documentée ou instable. »
Hors périmètre

Les profils Producteur et Développeur ont été identifiés et documentés comme condition de complétude du produit final, mais explicitement mis hors périmètre du POC — une décision de priorisation actée avec l'équipe, pas un oubli.

05
Décisions de conception

Les arbitrages qui
ont structuré le produit.

4 choix structurants

Réduction de la charge cognitive
Homepage structurée plutôt qu'atterrissage direct sur le catalogue
Le brief initial prévoyait de démarrer l'expérience directement sur le catalogue. J'ai défendu une homepage exposant les data domains, une barre de recherche centrale et des data products mis en avant — pour emprunter des patterns familiers et ne pas désorienter les profils novices dès l'entrée dans le produit.
Adoption & familiarité
Filtres en sidebar fixe plutôt que contextuels
Toujours visibles, cohérents avec ce que l'utilisateur connaît déjà (e-commerce, outils SaaS). Ce pattern réduit l'apprentissage nécessaire et adresse directement le pain point central identifié sur le CommonDataHub : la recherche défaillante.
Lisibilité vs exhaustivité
Fiche data product allégée, contre la demande initiale
Le commanditaire souhaitait des fiches très denses : cartes géographiques, KPIs multiples, business cases longs. Le benchmark montrait une tendance inverse. J'ai arbitré en faveur de la lisibilité, en compensant avec une navigation par tabs (Overview, Assets, Data Preview, Reviews) — absente des solutions benchmarkées — pour rendre l'information accessible sans la noyer.
Contrainte usage réel
Conception prioritaire sur 13" (1280px)
Compte tenu des usages réels chez ENGIE (cadres en déplacement, collaborateurs sans écran externe), j'ai conçu en priorité pour le 13" comme format contraignant, puis produit une version 1920px avec l'équipe dev. Tous les composants ont été construits avec des auto layouts pour garantir la scalabilité à chaque breakpoint.
06
Livrables

3 interfaces,
1 prototype fonctionnel.

En 2 semaines

Homepage
Barre de recherche centrale, exposition des data domains, sections Featured / Popular / Recently Added. Pensée pour guider le novice sans frustrer l'expert.
Catalogue
Affichage en cards ou en liste, filtres latéraux persistants par domain, asset type, tags et qualité. Vue responsive, colonnes adaptatives.
Fiche data product
Navigation par tabs, panneau metadata latéral, demande d'accès à un asset, data preview graphique, suggestions similaires et système d'avis.

L'ensemble a été conçu dans le respect du design system ENGIE (Fluid DS), en lien direct avec l'équipe Design System pour garantir l'alignement avec les derniers composants.

07
Résultats

Une approche validée
au-delà du POC.

Les interfaces ont été jugées claires, ambitieuses et cohérentes avec les besoins exprimés. Le commanditaire a noté leur convergence avec des travaux internes menés en parallèle — signe de solidité méthodologique.

Signal fort : bien que le POC n'ait pas remporté l'appel d'offre, le commanditaire a explicitement sollicité ma participation au design de la solution gagnante — reconnaissant la valeur de l'approche UX proposée indépendamment du contexte compétitif.

08
Réflexion critique

Ce que je ferais
différemment.

Apprentissage
Démontrer sur un problème précis plutôt que livrer un POC complet
Dans ce type de contexte — délai court, culture top-down, accès utilisateurs limité — j'ai fait le choix de produire un POC complet plutôt que de concentrer l'effort sur un pain point unique, validé et mesurable. Avec le recul, proposer de démontrer une solution précise sur un problème ancré dans des données terrain aurait probablement mieux servi la méthode UX face au commanditaire, et aurait laissé plus de place pour documenter les décisions au fil de l'eau — une étape que la rapidité du sprint a rendu difficile.
Outils utilisés
Figma Figma Make ENGIE Fluid DS