Cadrage et conception d'une application de pilotage des contentieux pour la filière juridique d'ENGIE — première vision consolidée et actionnable de l'exposition juridique du Groupe.
Le contexte de départ
ENGIE gère des centaines de contentieux à l'échelle mondiale. Jusqu'ici, ce suivi reposait entièrement sur des documents Word, des échanges d'e-mails et des consolidations manuelles — une situation jugée insuffisante sur le plan sécurité et opérationnellement intenable pour le management.
Concrètement : un manager souhaitant suivre l'avancée d'un litige devait relire l'intégralité du document, sans pouvoir distinguer les évolutions récentes du contenu antérieur. Produire un reporting impliquait de contacter chaque juriste individuellement. Et à l'échelle Groupe, personne n'était en mesure d'obtenir une vision consolidée de l'exposition juridique, ni d'être alerté à temps sur un litige critique.
Le projet avait déjà été initié depuis 6 mois avant mon arrivée, avec de nombreuses parties prenantes aux visions divergentes et une tendance collective à se précipiter sur les aspects techniques avant d'avoir défini le produit.
Initiative et périmètre étendu
Je suis intervenue avec un périmètre initial restreint : concevoir le formulaire de saisie des litiges et créer un lien avec Power BI. En pratique, j'ai rapidement compris qu'avancer sur l'interface sans avoir défini le produit était impossible, et contre-productif.
La qualité du reporting dépend entièrement de la qualité de saisie des juristes. Traiter le dashboard managérial de façon déconnectée du formulaire de saisie revenait à construire sur des fondations incertaines — un point que j'ai dû remettre régulièrement à l'agenda.
J'ai proposé de ma propre initiative une phase de cadrage structurée, en prenant le temps d'expliquer la méthode UX et l'utilité de chaque outil aux parties prenantes, dont certaines découvraient cette approche. Cette pédagogie a été un prérequis pour obtenir leur adhésion.
Design thinking appliqué
Face à un produit à créer de zéro — pas d'amélioration d'un existant, mais une digitalisation complète d'un processus papier — j'ai appliqué une approche design thinking structurée en m'appuyant sur la méthode du Product Vision Board pour les ateliers de cadrage.
Contrainte majeure — accès au terrain limité
La cliente principale a souhaité être l'unique porte-parole du métier, me privant d'accès direct aux juristes et managers. J'ai dû composer avec cette contrainte tout en défendant la nécessité d'une validation utilisateur en aval.
Atelier 1 & 2 — Product Vision Board
Clarification de la vision produit, des profils utilisateurs et des objectifs. Ces sessions ont ouvert des discussions jusqu'alors bloquées et permis d'identifier de nombreuses zones d'ombre sur le périmètre fonctionnel et les priorités de livraison.
Recherche utilisateur
Point d'attention : les juristes sont réticents au changement et le principal bénéfice du produit ne leur revient pas directement. L'enjeu UX est de réduire leur charge perçue au maximum et de leur rendre le bénéfice visible, notamment via un dashboard personnel montrant l'impact concret de leur saisie.
« Offrir à toutes les parties prenantes une visibilité claire, partagée et à jour des litiges du Groupe, afin de permettre un suivi et pilotage structuré, sécurisé et une intervention managériale au bon moment. »
J'ai également posé un cadre de lecture commun pour éviter la fragmentation technique : l'application est un produit unique avec un point d'entrée unique, que Power BI, Power Apps ou Dataverse opèrent en arrière-plan est invisible pour l'utilisateur.
Cette vision, illustrée par la métaphore des coulisses et de la scène, a été adoptée par l'ensemble de l'équipe projet et a mis fin aux discussions décorrélées entre les différents outils techniques.
Cette structuration en lots n'existait pas avant mon intervention. La clarifier a été une condition nécessaire pour permettre à l'équipe de prioriser et de lancer le développement de façon ordonnée.
5 principes de conception
J'ai identifié l'absence d'une liste consolidée des indicateurs souhaités pour les dashboards managériaux — un manque qui aurait bloqué le développement. J'ai pris l'initiative de construire cette liste par persona, en précisant pour chaque indicateur : son nom, sa représentation graphique souhaitée, son bénéfice attendu pour l'utilisateur et sa priorité.
J'ai ensuite fait valider la faisabilité technique de chaque indicateur avec l'équipe dev, puis soumis la liste priorisée au proxy PO. L'étape suivante — validation avec les utilisateurs lors d'un atelier dédié — est planifiée.