
[DEX+] SIGURD : refonte et formation d'un outil métier critique
SNCF Réseau • Janvier 2024 - Août 2025 • Product Designer
Introduction
79% des agents déclaraient ne pas être assez formés à l'outil qu'ils utilisaient quotidiennement.
Ce chiffre, issu de l'immersion initiale du programme DEX+, résumait une situation que j'avais observée sur le terrain : des utilisateurs qui contournaient les fonctionnalités, inventaient leurs propres méthodes et transmettaient leur savoir par “l'école de la vie” plutôt que par une formation structurée.
L'outil lui-même - SIGURD, un des outils métier des agents d'études DEX codé en AutoLisp - n'avait pas été maintenu depuis une dizaine d'années. Les performances se dégradaient, les bugs s'accumulaient. Et plusieurs Pôles d'Études et d'Ingénierie avaient développé leurs propres modifications pour compenser les lacunes, créant un patchwork de versions impossible à harmoniser nationalement.
Contexte
Le programme DEX+ préparait une solution de rupture - AEGIS ( lire le cas d'usage) - mais elle ne serait pas prête avant plusieurs années. En attendant, plus de 200 agents devaient continuer à produire des études de signalisation ferroviaire avec un outil défaillant et sans formation digne de ce nom.
SIGURD est né de cette urgence : améliorer l'existant rapidement, former les utilisateurs correctement et préparer le terrain pour la suite. Deux chantiers interdépendants devaient avancer en parallèle et se nourrir mutuellement : la refonte de l'outil et la création d'une toute nouvelle formation.
Mon rôle
Lead designer au sein d'une équipe de 6 personnes : une cheffe de projet PO, une responsable conduite du changement, 3 développeurs et moi.
J'ai travaillé en binôme étroit avec la cheffe de projet, dans une relation de complémentarité : elle apportait la maîtrise du contexte organisationnel et politique ainsi que l'orchestration de l'exécution opérationnelle, j'apportais la méthodologie centrée utilisateur (des activités de discovery à celles du delivery). Cette complémentarité s'est révélée décisive pour naviguer les résistances qui allaient se présenter.
Mon périmètre couvrait l'ensemble du design sur les deux axes : co-conception du dispositif de formation (structure pédagogique, support, kit clé en main), refonte de l'interface et des parcours de l'outil (audit, maquettes, spécifications, tests), et montée en compétence de l'équipe technique sur les méthodes UX - j'ai notamment formé les développeurs à conduire des micro-sessions de test pour qu'ils puissent valider leurs développements directement avec les utilisateurs.
Discovery
Ce qu'on croyait
Le cadrage initial posait un problème en deux volets séparés : d'un côté un outil à moderniser techniquement, de l'autre des agents à former. Deux axes, deux plans d'action, deux timelines.
Ce que le terrain a montré
L'audit technique - 3 semaines dans deux Pôles d'Île-de-France - a révélé que les deux volets étaient en réalité le même problème vu sous deux angles.
Les agents ne contournaient pas l'outil par incompétence. Ils le contournaient parce que l'outil ne leur permettait pas de travailler correctement. Les astuces qu'ils avaient développées - et que certains concepteurs de l'outil ignoraient - étaient des réponses rationnelles à des défaillances réelles. Les traiter comme des débutants à former aurait été une erreur de posture autant que de pédagogie.
Parallèlement, les 10 ateliers de co-construction menés avec 13 à 15 agents de différentes régions ont montré que les utilisateurs savaient précisément ce qui devait être enseigné, dans quel ordre et avec quels exemples. Ils étaient des experts de leur propre pratique.

Reframing
Former les agents sur un outil défaillant ne servirait à rien. Moderniser l'outil sans intégrer le savoir des utilisateurs produirait une nouvelle version déconnectée de leurs réalités. La formation devait enseigner les bonnes pratiques sur un outil qui allait évoluer. L'outillage devait intégrer les retours issus des sessions de formation.
Le parti pris a été de construire la formation avec les agents, pas pour eux - et de synchroniser les deux chantiers pour que chaque avancée de l'un nourrisse l'autre.
Conception
Trois décisions de design ont structuré les 20 mois du projet.
1. Co-construction plutôt que formation descendante
Plutôt que de rédiger un support pédagogique en chambre, nous avons sollicité 2 agents volontaires dans la co-rédaction des 4 chapitres de formation, dans le cadre défini ensemble lors des ateliers. Une véritable reconnaissance de leur expertise : ils savaient mieux que nous quels gestes métier prioriser et comment les formuler.
Le support final - 220 slides - intégrait du texte technique, des captures et vidéos pour les actions complexes, des quiz pour créer des moments d'échange et une identité visuelle cohérente avec le programme DEX+. L'enjeu était de produire un outil interactif, pas un PDF technique qu'on survole avant de l'oublier.

Pour garantir l'autonomie des Pôles, nous avons conçu un kit clé en main d'une vingtaine d'éléments : cahier des charges, modèles de communication, questionnaires d'évaluation pré et post-formation, guide d'animation, guide des étapes. Un Pôle pouvait télécharger le kit et lancer une formation la semaine suivante.
2 sessions pilotes ont permis d'itérer 3 fois le dispositif avant sa version définitive.

2. Refonte ciblée guidée par l'audit
L'audit initial - 3 semaines sur site, plusieurs mois de montée en compétence technique - a produit un plan d'action en plusieurs lots. Sans cette compréhension approfondie, nous aurions navigué à l'aveugle.
Le travail s'est organisé en cycles : ateliers de conception avec une quinzaine d'agents, prototypage, développement, tests et itération. J'ai produit les spécifications fonctionnelles permettant aux développeurs de naviguer entre documentation et maquettes - cette proximité a fluidifié les échanges et réduit les allers-retours.


Plus de 70 fonctions et parcours ont été retravaillés. Un UI kit d'interface unifié a été constitué : plus de cinquante icônes personnalisées, plus de quarante composants clés, des maquettes haute fidélité respectant les standards d'accessibilité (contrastes 8 à 9 selon le RGAA, modes clair et sombre, iconographie lisible en petite taille).



3. Un langage d'interface respectueux
Les principes définis - ton professionnel jamais condescendant, clarté absolue sans jargon, guidage constructif, formulations positives - ont transformé la perception de l'outil.
Exemple de message d'erreur :
Avant
“Fichier non trouvé !!!”
Après
“Le fichier est introuvable. Vérifiez son emplacement et son nom.”
Exemple de description de fonction :
Avant
“Pairage Insère le symbole de pairage sur les ligne sélectionnées (Verticales ou horizontales)”
Après
“PAIRAGE Insère le symbole de pairage approprié et reconnu par SIGURD pour le bornage sur la ligne sélectionnée. Lorsqu'un fil unique est utilisé, le symbole neutre est automatiquement inséré. Raccourci clavier CTRL+ALT+P”
Retravailler ces contenus un par un a contribué à changer la relation des agents avec leur outil.
Les obstacles traversés
La résistance aux habitudes installées
La fonction “Bibliothèque de symboles” illustre ce défi. Ergonomiquement obsolète et industriellement problématique, elle était pourtant solidement ancrée dans les routines des agents après des années d'usage. La refondre a demandé plus de temps, plus d'itérations et plus d'échanges que prévu.
À l'inverse, la fonction “Modèles d'étude” - puissante mais pénalisée par des parcours complexes - a bien accueilli sa refonte itérative. La différence : la seconde était une douleur reconnue par les utilisateurs eux-mêmes, la première ne l'était pas.
La coopération bloquée
Certains interlocuteurs ont freiné le projet : refus de partager le code source, refus d'un système de versionnage commun, posture critique sans contribution constructive. Ces obstacles ont imposé des contournements. La persévérance de l'équipe et le soutien des sponsors ont permis d'avancer malgré ces frictions.
Le développement double
Le passage d'AutoCAD 2022 à BricsCAD v23 puis v25 a imposé de tester chaque fonctionnalité dans deux environnements. Combiné à l'hétérogénéité des pratiques locales - chaque PEI avait ses propres modifications de code accumulées au fil des années - cela a représenté un investissement lourd mais nécessaire pour garantir une adoption nationale cohérente.
Impact
Déploiement
Quatre versions livrées (V1.1, V1.2, V2, V3). 200+ utilisateurs dans 16 PEI de France au 20 novembre 2025.
Qualité
97 bugs détectés et traités. 167 tickets de fonctionnalités conçus et développés. Tests unitaires et fonctionnels introduits - couverture dépassant 40% en AutoLisp et C#, quatre cahiers de tests fonctionnels par brique.
Adoption
NPS en forte progression, atteignant 50 sur la V2. 58 retours utilisateurs collectés, dont 44 traités en développement - 76% de prise en compte. Satisfaction formation : 4,6/5.
Efficacité
À Rouen, le traitement des indices d'un bordereau prenait “une demi-journée à une journée complète” selon les agents. Avec la nouvelle fonction “Modèles d'étude”, cette tâche s'effectue en quelques clics. Réduction moyenne des actions par parcours : ~40%.
Tests terrain
9 protocoles de tests menés dans 9 sites au niveau national - Dijon, Toulouse, Bordeaux, Strasbourg, Tours, Lyon, Rouen, Reims, Limoges.


Ce qu'en disent les agents
“
Dommage, vous avez trop bien bossé, j'ai l'impression que tout fonctionne.
Agent d'études, PEI Toulouse
“
En tout cas merci pour votre travail et votre réactivité - je n'ai pas l'habitude de ça.
Agent d'études, PEI Limoges
“
En repassant sur l'ancienne version, je me rends compte à quel point cette nouvelle expérience est meilleure.
Agent d'études, PEI IDF
“
Le fait de venir nous voir, se déplacer, nous expliquer, nous former, c'est une superbe démarche. On aurait aimé avoir eu ça pour les projets précédents.
Agent d'études, PEI Bordeaux
“
Cette version propose une meilleure expérience pour les jeunes et les nouveaux, car la prise en main est plus simple.
Agent d'études, PEI IDF
Enseignements
Ce projet m'a appris que la frontière entre “former” et “concevoir” est artificielle quand on travaille sur un outil métier critique. Les agents qui m'ont appris leurs contournements pendant les ateliers de co-construction sont les mêmes qui ont validé les nouvelles fonctions pendant les tests terrain, puis qui ont défendu le projet auprès de leurs collègues sceptiques.
L'audit approfondi - 3 semaines sur site, des mois de montée en compétence sur le code - a été l'investissement le plus rentable du projet. Chaque décision de conception qui a suivi reposait sur une compréhension concrète de ce que nous touchions. Sans cette fondation, nous aurions produit une nouvelle version “propre” mais tout aussi déconnectée des réalités terrain que la précédente.
L'enseignement le plus net est peut-être le plus simple : les verbatims le disent, les agents n'avaient pas l'habitude qu'on vienne les voir, qu'on les écoute, qu'on les forme. Cette attention - qui n'est rien d'autre que la démarche centrée utilisateur appliquée sérieusement - a créé une confiance qui a porté le projet dans les moments où la coopération institutionnelle faisait défaut.