Tester en conditions réelles
Compromis : Une date codée en dur a masqué un bug jusqu'en production. Depuis, je teste dans des conditions proches du réel, ce qui demande plus de temps de préparation avant la livraison.
← Retour au parcours
Application de trading chez Worldline
Pendant 2,5 ans, j'ai fait évoluer une application qui permet à des professionnels de la finance d'acheter et de vendre des titres en bourse.
Mes 2,5 ans chez Worldline
- Mars 2023Arrivée, développeur back-end
- PuisPassage fullstack, en équipe Scrum, du besoin à la mise en production
- Dernière annéeUne fonctionnalité portée seul, maquette validée avec le Product Owner
- Sept. 2025Fin de mission, 2,5 ans plus tard
Le problème
Une application de trading n'a pas droit à l'approximation. Quand on achète ou qu'on vend des titres, une erreur ne reste pas dans un fichier de log : elle se voit dans un ordre. Mon travail : livrer des évolutions complètes, de l'analyse du besoin à la mise en production, en équipe Scrum.
Les décisions
Valider la maquette avant de coder
Compromis : Sur une fonctionnalité portée seul, en dernière année, j'ai fait valider la maquette par le Product Owner avant le développement. Un échange de plus au départ, mais moins de retours en cours de route.
Le parcours d'un ordre
Le mur du 60e km
La complexité de la solution, et le respect de la Definition of Done : une évolution n'est terminée que lorsque tout est vérifié, testé et relu.
Ce que j'en retire
Travailler sur un système critique m'a appris la rigueur : analyser avant de coder, tester avant de livrer, et garder la tête froide quand tout va vite.