Sacha Froment

Modernisation, performance et fiabilité d'une suite d'applications métier de gestion des commandes (ASP.NET Core, Angular, SQL Server), au sein d'une organisation d'environ quinze développeurs. Au-delà des développements prévus, j'ai traité seul et de ma propre initiative le travail de fond qui conditionne la fiabilité des livraisons : modernisation du front, performance des tests et de la CI, restructuration de la couche visuelle et design system.

Modernisation du front-end

De ma propre initiative, j'ai mené seul la migration d'Angular 17 à Angular 21, de l'analyse à la mise en production. Pour les transformations que les outils officiels ne couvrent pas, j'ai écrit des codemods AST qui ont automatisé la réécriture du code. J'ai ensuite migré la suite de plus de 900 tests de Jest vers Vitest et je l'ai parallélisée : son exécution est passée d'environ 20 minutes à 30 secondes.

Intégration continue

J'ai mesuré puis optimisé seul le pipeline front, qui est passé de 30 minutes à 5 ou 6 minutes. Avec environ cinq exécutions par jour et jusqu'à dix-neuf les jours de pointe, cela représente près de deux heures d'attente gagnées chaque jour, et près de huit heures les jours chargés. J'ai également contribué à ramener le pipeline back de 20 à 7 minutes, dans le cadre d'un chantier partagé (environ neuf exécutions par jour).

Changelog automatique

J'ai mis en place un journal des livraisons généré par la CI/CD à partir des work items Azure DevOps. Il fonctionne en ajout seul : le pipeline reprend l'artefact changelog.json de la version précédente et y ajoute les work items livrés depuis la dernière version taggée. Le fichier est intégré à l'application, ce qui permet de suivre les livraisons depuis l'interface.

Performance applicative

J'ai profilé une page complexe, identifié des cascades de chargement séquentielles, puis je les ai supprimées : son affichage est passé d'environ cinq secondes à une seconde.

Thème et design system

J'ai repris de ma propre initiative une couche visuelle chaotique : composants instables ou difficiles à intégrer, couleurs disparates d'un écran à l'autre. Je l'ai restructurée en un thème cohérent fondé sur des variables partagées. Sur cette base, j'ai étendu et fiabilisé les composants du design system, chacun accompagné d'une page de démonstration, ce qui accélère le développement et garantit la cohérence entre les équipes.

Retour en temps réel

J'ai fait passer en temps réel plusieurs envois, en particulier les échanges interapplicatifs. L'utilisateur voit désormais le résultat immédiatement, sans rafraîchir la page. J'ai aussi enrichi les états d'erreur pour qu'un échec soit compréhensible sans passer par le support.

Recherche d'agence

J'ai refondu le parcours de changement d'agence, qui reposait sur une recherche fragile par code de ville. Je l'ai remplacé par une recherche floue instantanée (Fuse.js) sur la ville, l'adresse et les autres attributs de l'agence.

Profils et permissions

J'ai co-conçu un système transverse de permissions, désormais en production à la place de contrôles dispersés propres à chaque fonctionnalité. Le calcul des droits combine les groupes Active Directory, les données de l'utilisateur en base et la session, puis les rapproche de profils hiérarchiques et de règles dynamiques. Le même résultat pilote l'affichage dans Angular et les contrôles d'accès des API .NET. Le modèle est validé par de nombreux cas positifs et négatifs générés à partir des conditions d'accès, et revu avec les responsables produit. J'ai aussi participé à la normalisation des mécanismes d'authentification.

Intégration de prestations externes

J'ai intégré un système d'évaluation d'articles de commande à partir d'API de prestataires externes : règles de gestion, suivi et affichage des statuts, gestion des erreurs et journalisation des échanges.

Socle .NET

De ma propre initiative, j'ai centralisé les règles de build dans Directory.Build.props et verrouillé les dépendances. J'ai aussi évalué .NET 10 et Nix pour préparer les prochaines évolutions sans perturber la production.

Contexte

La suite échange des données au moyen d'API JSON, de flux interapplicatifs et d'un bus de services, avec l'introduction progressive de CQRS. Elle est développée par plusieurs équipes, soit environ quinze développeurs et quatre à cinq interlocuteurs produit, en Agile avec Azure DevOps. En l'absence d'équipe de test dédiée, les développeurs portent les tests automatisés.

Mission de deux ans sur les outils de configuration des systèmes ferroviaires embarqués. J'ai conçu et implémenté seul une CLI .NET 8 utilisée en production, préparé la migration de plusieurs dizaines de projets de NAnt vers MSBuild et fait évoluer des applications WinForms en .NET Framework.

CLI de production

À partir de spécifications techniques détaillant les formats binaires, la taille des champs et les règles d'échange, j'ai conçu et implémenté seul l'outil. La CLI produit des archives de données techniques destinées à certains systèmes du train, valide les documents XML selon des schémas spécialisés, contrôle la cohérence des données, puis chiffre et signe les fichiers. J'ai conçu des résultats typés, des diagnostics et des codes de sortie qui rendent chaque échec exploitable par les utilisateurs comme par les traitements automatisés.

Migration du système de build

J'ai préparé la migration du système historique de NAnt vers MSBuild sur plusieurs dizaines de projets C#. Au-delà de la traduction des scripts, j'ai analysé le graphe de dépendances, éliminé les risques de cycles, revu certains découpages et raccordé les modules de génération de code au cycle de build de Visual Studio.

Automatisation et transmission

J'ai écrit des outils qui automatisent les transformations répétitives tout en traitant explicitement les particularités de chaque projet. J'ai intégré le résultat à Visual Studio et à GitLab CI, puis documenté l'architecture cible pour que l'équipe poursuive le chantier.

Qualité

J'ai sécurisé les évolutions des outils de configuration et de comparaison par des tests NUnit unitaires et d'intégration, dans un environnement réunissant .NET Framework 4 et .NET 8.

Alternance de trois ans dans l'équipe de cartographie du système d'information. J'ai conçu et maintenu seul un framework TypeScript déployé sur près de 50 000 pages, puis conduit la migration de MEGA HOPEX V2R1 vers V5 jusqu'à sa mise en production, comme co-chef de projet MOE.

Refonte du front-end

J'ai conçu un framework TypeScript de 25 modules et environ 4 900 lignes pour refondre près de 50 000 pages générées par la plateforme. Son architecture apporte gestion d'état, hooks, montage sur un DOM existant et chargement dynamique, tout en conservant les échanges XML, JSON, SOAP et REST du système en place.

Déploiement et maintenance

J'ai déployé cette couche progressivement à la place d'une interface ancienne et contrainte en largeur. J'ai restructuré la navigation et les vues consacrées aux données métier, aux applications et aux technologies, puis ajouté des liens contextuels entre des informations auparavant isolées. J'en ai assuré seul la maintenance et les évolutions jusqu'à mon départ.

Build et intégration

J'ai construit l'outillage autour de Webpack 5, Babel, TypeScript et Sass, et uniformisé les builds et les déploiements entre environnements avec des scripts PowerShell. J'ai aussi fait évoluer les traitements d'extraction, d'import et d'API en VBScript et C#.

Migration de MEGA HOPEX

Comme co-chef de projet MOE, j'ai conduit la migration de V2R1 vers V5 : personnalisations, dépendances, scripts et infrastructure d'exploitation (IIS, SSO SAML2, sauvegardes et restauration SQL). J'ai pris en charge la réalisation technique, le cadrage, la préparation des opérations et la documentation de reprise, jusqu'à la mise en production.

Rôle temporaire consacré à l'inventaire et à la cartographie des technologies, serveurs et logiciels du système d'information, dans la continuité du travail mené sur la plateforme HOPEX.

Administration de 5 à 10 VPS OVH sous Linux pour l'hébergement de sites clients. Automatisation en Bash de la configuration, des sauvegardes, des déploiements et de la supervision d'une infrastructure LAMP.

Automatisation et exploitation

Des scripts Bash ont automatisé la configuration des serveurs, les sauvegardes, les déploiements et la supervision. L'exploitation reposait sur Apache, PHP, MySQL ou MariaDB, SSH et rsync. Une étude complémentaire a exploré l'automatisation de relevés bancaires par EBICS avec Ruby.