Axione
Aligner les parties prenantes pour réduire les incohérences de données
Une approche UX dans un contexte d'outil interne (plugin QGIS).
Alignement
Outil interne
QGIS
FME
Python
Date : 2024
Durée : 2 semaines
Contexte : Projet SIG (cartographie des réseaux) de 121 dossiers
Rôle : Référent UX et facilitateur (rôle sur le projet, distinct de mon poste officiel)
Utilisateurs : 5 opérateurs au démarrage, environ 25 personnes au fil du projet
Parties prenantes : 3 responsables d'étude (dont mon manager), 1 collègue développeur, le client
Outils : QGIS, FME
IN FRENCH ONLY
This case study is currently available in French only. An English version is in progress — expected in November.
2 sem.
Plugin développé et testé en interne
−50 %
Temps de production par projet avant/après le plugin (1–2 jours → ~0,5–1 jour), constaté sur les projets après stabilisation (4 itérations).
Personnes utilisant l'outil au fil du projet (5 au démarrage)
121
Projets traités
[Formes irrégulières (A) transformées par des règles de correspondance en formes homogènes (B)]
Au lancement d'un projet de 121 dossiers, l'outil existant s'est vite révélé inadapté : des exports FME à corriger et à compléter à la main, projet après projet. Chaque responsable appliquait ses propres règles, les attentes du client restaient floues, et une solution du département digital n'était pas attendue avant 1 à 2 mois.
Mon rôle : faciliter l'alignement entre le client, les responsables d'étude et le développeur pour transformer ces besoins ambigus en règles communes, puis tester avec l'équipe un plugin QGIS développé en interne en 2 semaines.
Résultat : environ 50 % de temps gagné par projet, et un outil adopté par toute l'équipe.
Le projet en 3 temps
PROBLÈME
Un outil existant inadapté (exports FME corrigés à la main), des règles de saisie différentes selon les responsables, des attentes client floues : une perte de temps et des incohérences à répétition.
DÉMARCHE
Obtenir des fichiers réels du client, aligner deux responsables d'étude sur une règle commune, formaliser le mapping A → B, puis 4 itérations de test.
RÉSULTAT
Un plugin QGIS développé en interne en 2 semaines, un temps par projet réduit d'environ 50 %, utilisé par l'ensemble des équipes du projet.
Correspondances A → B
SCHÉMA A → B
Exports FMEoutil interne(A)
Analyse des écarts
Règles de transformation
Tests et itérations
Attendu client(B)
Données confidentielles : exemples anonymisés et simplifiés.
À retenir
Le problème était organisationnel, pas seulement technique.
Transformer des données ambiguës en règles exploitables.
Formaliser les règles dans un document de référence partagé.
[Formes irrégulières (A) transformées par des règles de correspondance en formes homogènes (B)]
Contexte
Dans le cadre d'un projet SIG (système d'information géographique), notre équipe devait livrer 121 projets en 1 à 2 mois.
Le processus existant reposait sur des exports générés via FME (outil interne de transformation de données), suivis de corrections et de complétions manuelles. Cependant :
POINTS DE BLOCAGE
- Le département digital travaille en méthode agile, par sprints de 2 semaines. Le premier sprint ayant été manqué, et notre besoin n'étant pas forcément prioritaire au sprint suivant, le délai avant de pouvoir tester sur nos fichiers était incertain (estimé à 1–2 mois) ;
- Les règles de saisie variaient selon les responsables d'étude ;
- Les attentes du client n'étaient pas clairement définies.
Résultat : une perte de temps, des incohérences et des modifications à répétition.
MON RÔLE
Référent UX et facilitateur (rôle sur le projet, distinct de mon poste officiel). Je faisais le lien entre les attentes du client, les responsables d'étude et le développeur, afin de transformer des besoins ambigus en règles claires et testées.
Problème
Des symptômes à une cause commune
Question de départ : comment améliorer rapidement la productivité et la cohérence des données ?
Les symptômes (perte de temps, incohérences, allers-retours) avaient une cause commune :
LES CAUSES
- Des règles de saisie non unifiées ;
- Des attentes client ambiguës ;
- Plusieurs responsables aux visions divergentes ;
- Aucun mapping clair entre les données issues d'outil interne FME (A) et les attentes du client (B).
PROBLÈME CLÉ
Un manque d'alignement entre les parties prenantes. Le véritable enjeu n'était donc pas seulement de développer un outil, mais de concevoir cet alignement.
Parties prenantes
Des visions à aligner
RESPONSABLES D'ÉTUDE
3 responsables d'étude, dont mon manager : définition des règles, visions divergentes.
OPÉRATEURS
5 opérateurs au démarrage du projet (saisie et traitement des données), dont 1 collègue développeur (plugin Python / QGIS).
CLIENT
Validation finale.
Démarche
Quatre étapes, de besoins ambigus à des règles testées
Clarifier les besoins
CONTRAINTE
Je n'avais pas d'accès direct au client.
ACTION
Pour éviter de travailler sur des hypothèses, j'ai mobilisé mon expérience d'un projet similaire de l'entreprise pour convaincre mon manager de demander au client, avant le démarrage du projet, des fichiers réels et des exemples de résultats attendus, sous forme d'un fichier nomenclature pour le remplissage des données, plutôt que de définir les données en interne à partir de notre propre expérience.
RÉSULTAT
Une source de vérité fiable et des critères attendus plus clairs.
Aligner les parties prenantes
CONTRAINTE
Les responsables d'étude n'étaient pas d'accord sur les règles de saisie ni sur le niveau de qualité attendu. Sans standard, il était impossible de valider les résultats.
ACTION
J'ai contribué à convaincre deux responsables d'étude de définir une règle commune et d'éviter des logiques parallèles contradictoires.
PRINCIPE UX
La cohérence du système prime sur les optimisations individuelles.
Structurer la logique de transformation (A → B)
CONTRAINTE
Aucun mapping clair n'existait entre les outputs FME (A) et les résultats attendus par le client (B). Le projet comptait de nombreuses sous-unités, chacune avec plus de 10 champs nécessitant des règles de mapping différentes.
ACTION
J'ai vérifié et corrigé ce mapping en comparant systématiquement les deux, en m'appuyant sur les exemples réels du client comme source de vérité. Plutôt que de corriger au cas par cas, j'ai identifié des patterns récurrents et aidé à les formaliser en règles de transformation.
SCHÉMA A → B
Exports FMEoutil interne(A)
Analyse des écarts
Règles de transformation
Tests et itérations
Attendu client(B)
Données confidentielles : exemples anonymisés et simplifiés.
Itérer et valider
ACTION
Avec deux collègues, nous avons comparé l'ensemble des données entre l'output initial, l'output du plugin et l'attendu client. J'ai rédigé les rapports de test : après chaque mise à jour du plugin, j'y consignais les résultats ainsi que les problèmes de mapping identifiés.
RÉSULTAT
4 itérations ont été nécessaires pour stabiliser la solution.
Solution
Un plugin QGIS développé en interne
Plutôt que d'attendre un prochain sprint du département digital, nous avons développé et testé le plugin en interne en 2 semaines, avec un collègue ayant des compétences en Python.
LE PLUGIN QGIS PERMET DE
- Automatiser une grande partie de la saisie ;
- Appliquer des règles homogènes ;
- Réduire les corrections manuelles.
Les règles de transformation ont été établies et testées par rapport aux exigences de données du client, puis formalisées dans un document de référence partagé.
Résultats & impact
L'outil a été adopté par l'ensemble des équipes du projet : environ 25 personnes, sur 121 projets.
AVANT
APRÈS
Mise à disposition de l'outil
Délai incertain, estimé à 1–2 mois (sprints du département digital)
2 semaines (développement interne)
Temps par projet
1–2 jours (correction entièrement manuelle)
~0,5–1 jour (environ −50 %)
Utilisateurs
5 opérateurs au démarrage
Environ 25 personnes au fil du projet
Volume
Projet test parmi les 121 projets
121 projets
GAINS OBSERVÉS
- Productivité accrue ;
- Cohérence des données améliorée (constat qualitatif, non mesuré) ;
- Réduction des allers-retours.
Ce que j'ai appris
Ce projet m'a permis de comprendre que le principal défi n'était pas de développer un outil, mais de concevoir un alignement entre des interprétations divergentes et d'établir un process pour le projet.
CE QUI A FONCTIONNÉ
Identifier que le problème était organisationnel, pas seulement technique.
Transformer des données ambiguës en règles exploitables.
Aligner, même partiellement, les parties prenantes malgré des contraintes hiérarchiques.
Formaliser les règles dans un document de référence partagé.
AMÉLIORATIONS POSSIBLES
Aligner plus tôt : proposer d'organiser un workshop dès le départ.
Définir des métriques : taux d'erreur, nombre de corrections, etc.
J'ai ainsi joué un rôle de pont entre des attentes client floues, des contraintes internes et une implémentation technique.
Thanks for reading — your questions are welcome :)
PREVIOUS · CASE STUDY 01
Reducing the complexity of a technical workflow
An onboarding system for non-expert colleagues.
NEXT · ABOUT
Who am I?
My path, from landscape design to Product Design.