May 1, 2024

Context

Project CAPELLA is a critical CRM application built for a major energy utility (Enedis), used daily by thousands of client advisors across France. I worked on it for nearly two years as part of a Thales team, on a codebase that had to keep running reliably in production while continuing to absorb new business requirements. Stack: Java, Spring, Angular, FitNesse, Maven, Git.

Constraints

• Scale of usage — the CRM is a daily working tool for thousands of advisors nationwide, so any regression has a direct and wide-reaching operational impact.
• Maintainability — a long-lived codebase shared across a large team, requiring changes that stay consistent with existing conventions and don't increase technical debt.
• Continuous functional evolution — the business kept requesting new features and adjustments, which had to be delivered without destabilizing existing behavior.
• Stability under regular release cycles — production releases happened on a recurring schedule, leaving limited room for unverified or poorly tested changes.

Contribution

• Developed and maintained new features across the backend (Java/Spring) and frontend (Angular) layers of the CRM.
• Analyzed existing functionality and business requirements to design changes that fit cleanly into the current architecture.
• Wrote automated tests with FitNesse to validate business rules and reduce the risk of regressions on each delivery.
• Investigated and resolved complex functional and technical issues surfaced during development and testing cycles.
• Took part in regular production releases and presented delivered user stories to business stakeholders, including sessions in front of audiences of 60+ people.

Approach

Working on a CRM of this size meant treating every change as part of a long-term maintenance effort rather than an isolated task: understanding how a feature interacted with the rest of the platform before modifying it, and favoring incremental, testable changes over broad rewrites. FitNesse-based automated tests were used as a safety net around business logic, making it possible to move at the pace the business required without sacrificing confidence in what was already working. Balancing delivery pressure with quality meant being deliberate about test coverage on the areas most exposed to regressions, and using the recurring release cadence and stakeholder presentations as checkpoints to validate that what was built actually matched business expectations before it reached advisors in production.

Outcome

The work contributed to a CRM platform that continued to evolve functionally while remaining stable for the thousands of advisors relying on it daily. The combination of automated testing and regular release involvement helped keep regressions contained and gave business stakeholders visibility into delivered work through recurring presentations, reinforcing trust between the engineering team and the business side.