The client and the context
Ifremer, the French national institute for ocean science, runs the Fisheries Information System (SIH), the national network that monitors fishery resources and the activity of French fishing fleets. Observers collect the data in the field, at fish auctions, at landing or on board vessels. The data then feeds the institute’s research and expert advice.
Before it is used, the data is checked in Valparaiso, an R Shiny application. Observers find the anomalies detected in their own entries, then Ifremer’s coordinators check the whole set. The application has five modules, including fish auction sales, landings in the French overseas territories and biological measurements of fish.
The Activity module gives an idea of the volumes. Each year, in the first quarter, about fifty observers use it to check the activity calendars of about 6,000 vessels. The other modules are used all year round.
Valparaiso has existed since 2021. First written by Ifremer developers, then by a contractor, it became the subject of a public maintenance contract in 2025, which we won. Since September 2025 and for four years, we handle its corrective maintenance, its preventive maintenance and its new features, which Ifremer orders quarter by quarter.
The problem
An audit commissioned by Ifremer in 2024 had set out the situation. The application had become hard to maintain, and its users reported slowness and crashes. When we arrived, the code contained no automated tests.
Ifremer was therefore looking for a team specialized in R Shiny that could also work on the Java API connecting the application to the databases.
The constraint came from how the application is used. Valparaiso is in use all year, each module following its own checking calendar. It had to be fixed and extended while the teams were using it.
What we did
Start with an assessment. The contract provided two months to get to know the existing system. We went to Nantes, where Ifremer’s teams introduced us to the SIH and showed us each module. We reviewed the R code and audited the Java API, and our UX expert interviewed six users. This work produced an assessment that describes the architecture, the weaknesses of the code and what users expect, with recommendations ranked by priority.
Stabilize before adding. At the first steering committee, we agreed with Ifremer on an order of work: the first quarter would go to fixes and to putting the code in order, and business features would come next. So we started by reorganizing the application’s code. To make sure nothing had changed for users, Ifremer tested this version by comparing it with the one in production, module by module, before it went live at the end of the quarter. We then added automated tests to the delivery pipeline, which now blocks a version when a test fails.
Deliver often, and leave production to the client. Every fix follows the same path. We deliver it to a validation environment, Ifremer’s designated users test it, then the institute’s IT department puts it into production. A progress meeting takes place every two weeks, and a steering committee every quarter.
The challenge: the screen that turns gray
Among the crashes, all users described the same one. In the middle of their work, without having clicked anything, the screen turned gray and the application stopped responding, with no error message to explain what had happened.
With no message, the cause had to be found by measuring. We replayed usage scenarios on the five modules while recording memory consumption at regular intervals. The curves showed that the application kept in memory the data of users who had already left. It eventually reached the limit set by the server, which stopped it and disconnected everyone. We therefore changed the way the application is launched, so that memory is released when no one is connected anymore.
That fix was not enough. The problem came back a few months later, reported this time by Ifremer’s IT department, and it took a second corrective version with finer optimizations in the data processing. Ifremer then observed far fewer disconnections.
The results
Valparaiso was fixed while its teams were using it. In one year, more than a dozen versions went to production, each tested by Ifremer before going live. Over these versions, its team saw the list of anomalies to fix get shorter.
The institute’s IT department benefited too. Each new version took up too much space on its servers, and it had asked us to reduce the application’s Docker image, which went from 5.7 GB to 2 GB.
Work continues on the Activity module. It is used only a few months a year, so observers have to be retrained before each campaign. We delivered a series of changes requested by its coordinator, and our designer rethought the checking workflow, which three Ifremer users tested on a mockup. This new interface is due to be in service for the January 2027 campaign.
Do you have an R Shiny application in production, written by others, to maintain or extend? Get in touch.