Vincent Douay
ÉTUDE 03 / 03Toutes les études →

ÉTUDE DE CAS 03 — SNCF · MISSION EXTIA

Consolider plus de dix flux hétérogènes pour les approvisionneurs

Au technicentre de Nevers, l'anticipation des stocks de pièces de trains reposait sur des croisements manuels de fichiers. Quatre ans sur Collector+, depuis le technicentre d'Hellemmes, pour transformer ça en analyses automatiques — et moderniser la plateforme au passage.

MON RÔLE

Ingénieur d'études — conception & développement du module

PÉRIODE

2017 — 2021 · basé au technicentre SNCF d'Hellemmes

PRODUIT

Collector+ — gestion de la réparation des pièces du matériel roulant

STACK

PHP · XML/SOAP · XLSX · MySQL → PostgreSQL · Jenkins · Docker

— LE PROBLÈME

Pour anticiper les besoins en pièces, les 5 à 6 approvisionneurs du technicentre de Nevers croisaient chaque semaine, à la main, plus d'une dizaine de sources : des flux XML/SOAP d'applications du siège, des fichiers XLSX produits par les technicentres, chacun avec son format, ses colonnes, ses pièges.

Résultat : un travail long, répétitif, propice aux erreurs — et aucune vue consolidée. En parallèle, l'application vivait sur une version obsolète de Windows Server et une base MySQL vieillissante : la modernisation ne pouvait pas attendre non plus.

— LES DÉCISIONS D'ARCHITECTURE

1Partir du terrain, pas du cahier des charges

Avant d'écrire une ligne de code : des sessions « vis ma vie » avec les approvisionneurs, pour comprendre leurs croisements réels, leur vocabulaire ferroviaire et ce qu'ils vérifient vraiment. Le workflow de l'interface découle directement de ces observations.

2Un modèle pivot, un connecteur par flux

Chaque source — SOAP, XML, XLSX — est normalisée vers un modèle de données commun par un connecteur dédié. Ajouter un flux, c'est écrire un connecteur, pas toucher au cœur. Les imports sont planifiés, journalisés et rejouables ; les données douteuses partent en quarantaine plutôt que de polluer l'analyse.

3Moderniser le socle : Windows → Linux, MySQL → PostgreSQL

J'ai piloté la migration des serveurs vers Linux et de la base vers PostgreSQL — pour sortir de la dépendance à un Windows Server obsolète et gagner en performance sur les volumes croissants d'imports. Docker a uniformisé les environnements ; la CI Jenkins exécutait les tests unitaires à chaque livraison.

— L'IMPLÉMENTATION

Le module a été livré par itérations, flux par flux, avec validation des approvisionneurs à chaque étape : d'abord les sources les plus douloureuses à croiser, puis les cas particuliers. L'interface CRUD et les écrans d'analyse reprenaient exactement leur terminologie métier.

La conteneurisation Docker, pensée pour accélérer l'onboarding, a eu un bénéfice imprévu : lors du premier confinement, l'équipe est passée en télétravail du jour au lendemain, environnements identiques à la maison. J'ai aussi accompagné 4 à 5 nouveaux développeurs sur la stack et documenté le workflow d'équipe.

— LES RÉSULTATS

10+ flux

Consolidés automatiquement — le croisement manuel des données a disparu

5-6 métiers

Approvisionneurs équipés au quotidien, un temps considérable rendu au métier

4-5 devs

Accompagnés sur la stack — et une équipe passée en télétravail sans friction en 2020

AVEC LE RECUL

« La normalisation vers un modèle pivot est la décision qui a tout simplifié : elle a rendu le système extensible, testable, et compréhensible par ceux qui l'utilisent. Les meilleures architectures naissent souvent d'une journée passée à côté des utilisateurs. »