[DEX+] AEGIS : 2,5 ans de discovery pour un outil qui n'a jamais vu le jour - et pourquoi ce n'est pas un échec
SNCF Réseau • Juin 2023 - Décembre 2025 • Lead Product Designer
Introduction
AEGIS est un outil de CAO (conception assistée par ordinateur) pour les agents d'études DEX de la signalisation ferroviaire. Ce cas d'usage couvre 2,5 ans de discovery : recueil des besoins utilisateur, spécification fonctionnelle, orientation technique.
Il raconte aussi ce que ces 2,5 ans ont produit de concret - et pourquoi un projet peut s'arrêter sans avoir échoué. Fin 2025, une décision politique et financière a mis fin au projet avant le lancement du développement. AEGIS n'a jamais été développé.
Contexte
Les agents qui dessinent les schémas électriques des installations ferroviaires, les agents d'études DEX (Documents d'EXécution) travaillent avec des outils de Dessin Assisté par Ordinateur. Concrètement, ils tracent des lignes et des symboles - exactement comme sur papier, mais avec une souris. Quand un élément change, ils reportent manuellement la modification sur tous les documents concernés, parce que l'outil ne comprend pas ce qu'il dessine. Il voit des traits, pas un circuit électrique avec sa logique propre.
AEGIS partait d'une vision différente : dessiner un schéma devait simultanément construire un modèle du circuit. Ce modèle propagerait automatiquement les modifications, vérifierait la cohérence selon les règles métier et permettrait de simuler le fonctionnement avant l'installation physique. Le passage du Dessin Assisté à la Conception Assistée par Ordinateur - un changement de paradigme, pas une simple amélioration d'interface.
Les promesses
- Conception et simulation des circuits électriques
- Vérification automatique des règles métiers
- Homogénéisation des schémas à l'échelle nationale
- Génération automatique de certains schémas dérivés (bornage, étiquettes...)
- Importation intelligente et assistée des collections de schémas existantes grâce à la reconnaissance d'image
Un benchmark de plusieurs mois - échanges avec des gestionnaires d'infrastructure internationaux, des industriels du naval et de l'énergie - avait conclu qu'aucun outil du marché ne couvrait le besoin. Le sur-mesure a été retenu. AEGIS était le fer de lance du Programme DEX+, pensé pour les années à venir.
Mon rôle
Lead Product Designer au sein de l'équipe coeur du projet, sur toute la durée des 2,5 ans.
Mon périmètre couvrait la conception sur mesure de la méthodologie de discovery (activités de recherche, modèle de cas d'usage, canevas de conception, cycles de travail), la conduite des ateliers nationaux avec les agents terrain, la contribution aux preuves de concept (analyse d'images et simulation), la rédaction des restitutions et la préparation de la phase de conception détaillée. J'ai également eu la chance de pouvoir encadrer plusieurs designers qui intervenaient sur le projet.
Sur un projet de cette nature - de la discovery pure sans phase de développement - la contribution de design ne se mesure pas en écrans livrés mais en qualité de la compréhension construite et en exploitabilité des livrables pour l'équipe qui reprendra.
Discovery
Ce qu'on croyait
Le cadrage initial positionnait AEGIS comme un projet de développement logiciel classique : spécifier, concevoir, développer, déployer. La discovery était une étape préliminaire, pas le coeur du projet.
Ce que le terrain a montré
Un an et demi d'exploration avant le lancement officiel avait déjà posé des fondations - mais AEGIS nécessitait d'aller beaucoup plus loin. La complexité métier était vertigineuse : des technologies de postes variées, des disparités de procédés entre les agents d'études DEX des 18 Pôles d'Études et d'Ingénierie (PEI), des interfaces SI critiques, et un domaine - la signalisation ferroviaire - où l'erreur a des conséquences sur la sécurité.
Deux preuves de concept ont été menées en parallèle.
POC analyse d'images
L'analyse d'images visait à importer les milliers de collections de schémas existantes dans AEGIS - des scans papier et fichiers vectoriels variés qu'il fallait transformer en modèles intelligents par reconnaissance de symboles, extraction de texte et reconstruction sémantique.
POC simulation
La simulation visait à permettre la vérification du fonctionnement d'un circuit avant installation physique. Un simulateur fonctionnel a été développé, démontrant la faisabilité technique.
Les dix ateliers nationaux menés avec vingt-sept participants de 18 PEI ont produit 205 cas d'usage et 35 scénarios utilisateurs. Les agents n'étaient pas des validateurs passifs : ils étaient des co-constructeurs.
Reframing
La discovery n'était pas une simple étape préliminaire. Sur un projet de cette complexité, elle était pleinement le projet. Accepter cette réalité a changé notre façon de travailler : chaque cycle de trois semaines devait produire des livrables exploitables, pas seulement des "pistes, zones d'ombre ou angles morts à approfondir". La rigueur industrielle - traçabilité de bout en bout entre le besoin terrain et l'exigence technique - est devenue notre mode de fonctionnement et non pas un idéal lointain.
Conception
Sur un projet arrêté avant le développement, le craft ne se mesure donc pas en interfaces livrées mais en enseignements et outils méthodologiques créés pour structurer cette complexité. Trois contributions ont défini le processus industriel centré utilisateurs.
1. Le modèle de cas d'usage en 3 dimensions
Avec l'équipe coeur, j'ai conçu un modèle qui est devenu le langage commun du projet. Chaque cas d'usage se structurait en contexte (quel acteur, quel problème), besoin (quel objectif, indépendamment de la solution) et attente (quel résultat mesurable). Cette structure dissociait volontairement le problème de la solution, gardait l'ancrage utilisateur et construisait la traçabilité de bout en bout.
2. Les outils de conception détaillée
Un hub central listait tous les sujets fonctionnels formulés à partir des exigences et cas d'usage - chaque sujet pouvait être discuté, trié, priorisé. Un canevas structurait ensuite chaque sujet en cinq sections : carte de visite, scénarios d'usage, parcours utilisateurs, spécifications opérationnelles, registre des risques. Ces outils garantissaient la cohérence tout en permettant une priorisation itérative.
3. Trois principes de design produit
La cohérence comme fondation : modifier un folio devait automatiquement maintenir la cohérence de la collection vis-à-vis des installations réelles, parce que l'incohérence dans ce domaine a des conséquences sur la sécurité ferroviaire. L'information plutôt que l'automatisme aveugle : l'agent devait être informé des impacts avant de valider, disposer d'un historique complet, rester maître de son travail. Et la minimisation de la résistance au changement : l'amélioration devait être perceptible immédiatement, pas promise pour plus tard.
1. Le modèle de cas d'usage en 3 dimensions
Avec l'équipe coeur, j'ai conçu un modèle qui est devenu le langage commun du projet. Chaque cas d'usage se structurait en contexte (quel acteur, quel problème), besoin (quel objectif, indépendamment de la solution) et attente (quel résultat mesurable). Cette structure dissociait volontairement le problème de la solution, gardait l'ancrage utilisateur et construisait la traçabilité de bout en bout.
2. Les outils de conception détaillée
Un hub central listait tous les sujets fonctionnels formulés à partir des exigences et cas d'usage - chaque sujet pouvait être discuté, trié, priorisé. Un canevas structurait ensuite chaque sujet en cinq sections : carte de visite, scénarios d'usage, parcours utilisateurs, spécifications opérationnelles, registre des risques. Ces outils garantissaient la cohérence tout en permettant une priorisation itérative.
3. Trois principes de design produit
La cohérence comme fondation : modifier un folio devait automatiquement maintenir la cohérence de la collection vis-à-vis des installations réelles, parce que l'incohérence dans ce domaine a des conséquences sur la sécurité ferroviaire. L'information plutôt que l'automatisme aveugle : l'agent devait être informé des impacts avant de valider, disposer d'un historique complet, rester maître de son travail. Et la minimisation de la résistance au changement : l'amélioration devait être perceptible immédiatement, pas promise pour plus tard.
Les obstacles traversés
La complexité irréductible du métier
Comprendre les techniques de signalisation ferroviaire n'était jamais terminé. Même après 2,5 ans, de nouvelles subtilités émergeaient. Estimer les délais de développement restait difficile parce que chaque brique fonctionnelle avait sa propre complexité.
Le financement instable
L'impossibilité d'obtenir un budget pluriannuel créait des décalages au démarrage de chaque phase, obligeant à adapter le planning régulièrement tout en maintenant le cap sur les objectifs.
Les obstacles humains
Certains interlocuteurs ont constitué des obstacles actifs plutôt que des partenaires. Naviguer ces tensions, contourner les blocages, persévérer malgré les résistances a demandé une énergie considérable qui aurait pu être consacrée au projet lui-même.
La fin
Fin 2025, un rebondissement politique et financier a tout arrêté. Mon dernier livrable officiel a été le retour d'expérience du programme - trois ans de travail condensés dans un document qui raconte le récit, les décisions prises et leurs raisons, les enseignements tirés, le capital méthodologique accumulé. Ce n'était pas une obligation administrative : c'était une conviction personnelle que ce travail avait de la valeur et devait être préservé pour ceux qui reprendraient le sujet.
Impact
AEGIS n'a pas atteint le déploiement. Les projections financières (gain de productivité de ~15%, soit 3,5 à 7M€ annuels estimés) restent des hypothèses - fondées sur des données terrain, mais des hypothèses.
Ce qui n'est pas une hypothèse, c'est ce qui a été produit :
Spécification
400+ éléments de spécification, avec 70% des exigences directement issues des cas d'usage développés avec les utilisateurs. Un chapitre introductif, un glossaire métier partagé, une nomenclature des exigences, des hypothèses de travail documentées.
Recherche
205 cas d'usage construits avec 50 agents de 18 Pôles régionaux. 10 ateliers réalisés, satisfaction 4,3/5, 300+ pages de restitution au total.
Preuves de concept
Un simulateur fonctionnel prouvant la faisabilité technique, un processus d'analyse d'images pour l'import des collections existantes.
Méthodologie
Un modèle de cas d'usage, un canevas de conception, des cycles de travail documentés - une méthodologie de discovery réplicable.
Réseau
50 agents engagés dans la co-conception, prêts à reprendre si le projet redémarre.
Ce capital existe et conserve sa valeur indépendamment du sort du projet.
Enseignements
La discovery n'est jamais terminée, et c'est normal.
Même après 2,5 ans, de nouvelles questions émergeaient. Accepter cette incomplétude permanente tout en produisant des livrables exploitables est un équilibre que peu de méthodologies enseignent - il s'apprend sur le terrain.
Les bons outils n'existent pas avant qu'on les crée.
La démarche centrée utilisateur, le modèle de cas d'usage, le canevas de conception, les cycles de travail : aucun n'existait avant AEGIS. Ils ont émergé des besoins réels. Parfois, la bonne réponse n'est pas d'appliquer une méthode mais de construire la sienne, convaincre et prendre le temps pour correctement l'appliquer.
Un projet peut s'arrêter sans avoir échoué.
AEGIS n'a pas été développé, mais il a produit une base de connaissances qui n'existait nulle part, une méthodologie rodée, et un réseau d'utilisateurs engagés. Trois ans de travail méritaient d'être préservés - pour ceux qui reprendront.