How IMA brings performance testing closer to developers with Gatling

IMA at a glance

IMA is a European assistance group founded in 1984. It provides 24/7 services such as roadside assistance, emergency call handling (eCall/bCall), and more recently, reinsurance products.

IMA is currently consolidating its technology organization into a unified Group IT Department. This reorganization aims to harmonize tools, governance, and engineering standards across the group’s French and international entities.

Gatling is now part of that shared engineering foundation.

From centralized load testing to performance as code

Before adopting Gatling, IMA already used another load testing solution, but wanted to move to a developer-driven, Test-as-code approach. Also, performance testing was primarily handled by a dedicated team and used mainly for large-scale or high-visibility projects. This approach, while effective in some contexts, limited coverage and kept performance validation relatively centralized.

“The objective was to make developers responsible for the scalability of their applications, using tools and languages they already work with,” shared Mehdi.

Because most of IMA’s systems are developed in Java, Gatling’s Java SDK aligned naturally with their existing skills. Simulations are written directly by development teams and versioned alongside application code in the existing source code management solution. Tests are typically triggered through CI pipelines when preparing release candidates. Performance testing, thus, became part of the delivery workflow rather than a separate validation phase.

Testing applications and shared infrastructure

IMA operates a distributed, API-centric architecture. Many shared infrastructure components — including authentication services, messaging platforms, and API gateways — are used across multiple applications. Their performance characteristics, therefore, have broad impact.

Gatling is used to test not only business applications, but also core platform components such as identity and access management services, messaging middleware, and API management layers. This allows teams to evaluate how much load these elements can sustain under realistic conditions and provides clearer visibility into scalability limits before those limits are reached in production.

“We use Gatling to understand precisely how much load a component can handle. We can define acceptable thresholds and identify the point where error rates start increasing.”

Integrated into CI and adapted to infrastructure constraints

Performance tests are generally executed when a team prepares a release candidate. Because IMA operates a hybrid infrastructure — with environments both on-premises and on a managed cloud Kubernetes platform — it uses separate control planes and private load injection locations aligned with network architecture.

Given that parts of the infrastructure are shared with operational systems, performance tests are coordinated to avoid unintended impact. This creates a balance between developer autonomy and operational caution. So, in IMA’s case tests are not scheduled on a fixed cadence, but triggered as needed by development teams within this governance framework.

From detection to correction

One concrete example illustrates the impact of this model. During testing of a geolocation-related application, a Gatling simulation revealed significant performance degradation under load. Error rates were high, and response times unstable.

The development team analyzed the results, identified structural issues in the code, and implemented corrective changes. A new test run showed stable metrics and the disappearance of error spikes.

“We immediately saw the difference between the two runs,” recalls Mehdi. “The first one clearly exposed the issue. After the fix, the results stabilized. That allowed us to proceed with confidence.”

Because the test was executed before deployment, the issue was resolved upstream rather than discovered in production.

Shared visibility and collaboration

Today, approximately fifteen to twenty engineers actively use Gatling across IMA’s Group IT Department, and adoption continues to expand.

Each team maintains its own simulations, which are stored and versioned alongside the relevant codebase. Results are automatically shared via Microsoft Teams notifications, providing visibility across teams whenever a simulation is executed.

Performance testing has become a collaborative discipline rather than a centralized service and what initially started as a developer-focused initiative has been adopted by middleware teams, who now use Gatling to validate the robustness of shared infrastructure components.

Linking load testing with observability

IMA uses an observability platform as part of its monitoring stack and is currently strengthening integration between load testing and infrastructure metrics. Correlating Gatling simulations with telemetry data helps teams better understand how systems behave under stress and where bottlenecks originate.This connection between synthetic load and real infrastructure metrics enhances analysis without fundamentally changing the workflow: developers remain responsible for interpreting results and implementing improvements when necessary.

A gradual, structural shift

As IMA finalizes its transition to a unified Group IT Department, the focus is on extending performance testing practices consistently across entities. The objective is not to introduce radical process changes, but to normalize performance validation as a standard engineering habit.

“Our goal is to continue building the practice,” expands Mehdi. “Performance testing should be part of the natural workflow, not an exceptional activity.”

In an environment like IMA’s where system reliability directly supports people in critical situations, that early visibility is essential. Therefore, by integrating Gatling into CI pipelines and aligning it with developer skills, IMA has strengthened its ability to detect scalability issues early and address them before they affect operational services.