The client and the context
Réseau Grandir Ensemble follows vulnerable children in the Pays de la Loire region of France, born prematurely or with a severe condition, from birth to the age of seven. About 300 referring physicians carry out the consultations, supported by a coordination team of about five people.
Ghislain Leduc, the network’s epidemiologist, had written a Shiny application himself for this team. You enter a family’s address, and a map shows the closest professionals in the network. The team had been using it for more than a year.
The problem
The network wanted to open this tool to the referring physicians, and the application was not ready. Access relied on a few passwords managed by hand, and the free hosting gave loading times that were too long.
The specifications set another condition. Once the tool was delivered, the network had to be able to handle maintenance, hosting, user management and further development itself. In fact, it asked for two quotes, one to have the application developed, the other to train its epidemiologist to do it. The network chose the first without giving up that condition: we had to deliver an application that Ghislain would be able to take over.
The interface redesign, carried out in the same project, is covered in another case study.
What we did
Read the code before deciding. We started with an audit. The network received a deliverable that reviews the code organization, authentication, tests and deployment, with a finding and a recommendation for each topic. It concludes: “The current application will not be rewritten in full.”
So we kept what worked, meaning the distance calculations, the map, the data processing, the file-based storage and the tracking of package versions with renv. And we redid what prevented opening the tool to physicians. Authentication moved to Auth0, with different rights for the coordination team and for physicians, and the application left the free hosting for a server rented by the network. The code itself was split into short modules, written according to conventions that an automated check verifies.
Install everything on the client’s side. The network had to handle maintenance and hosting itself. The code therefore stayed in the original GitHub repository, and that is where we delivered our work. When a change arrives there, a pipeline checks the code, builds the application and deploys it to the network’s server. An end-to-end test ships with the application.
Train the person taking over. Documentation and mentoring were in the contract on the same footing as development. We wrote a server maintenance guide and held three mentoring sessions, recorded so that Ghislain Leduc could watch them again. The first two covered the code architecture, then deployment and the server.
The challenge: the same screen copied three times
The original application had three pages, for referring physicians, for allied health professionals and for care facilities. Each page had its own map, list and filters, and the code of each repeated that of the other two with a few variations, so a fix had to be made three times.
Merging this code first required reading it block by block, to understand what depended on what. In a Shiny application, a calculation reruns when a value it depends on changes, and these links are not written down anywhere.
We then gathered this code into a single module, which the application calls three times with a different parameter. A fix is now made in one place.
The results
The application was delivered for acceptance testing five weeks after kickoff, and it has been in production since January 2026. A few months later, Ghislain Leduc confirmed to us that it was rolled out to the network and was causing no problems.
The network wanted to maintain the application without a vendor, and that is what it does. Seven months after going to production, Ghislain Leduc carried out his first maintenance alone, updating R and all the application’s packages. He had asked us to remain reachable just in case, and he called on us very little.
The update did cause a problem, as often happens when changing R versions: the application no longer built. The pipeline then did its job. It refused to deploy the new version, and the physicians kept using the one that was online. Ghislain Leduc found the cause himself, and the fixed version was in production less than two hours later.
He continues to develop in Shiny, and he asked us for advice on a new application he is writing.
In his testimonial, Ghislain Leduc highlights “the pedagogical approach you demonstrated” and mentions the audit, “which, beyond laying the foundations for what you were going to implement, was also a major driver for improvement for me, very useful going forward”. He also spoke about what comes next: “there are a number of developments that I will probably be able to implement myself”.
Do you have a Shiny application written in-house to take to production, and do you want to stay in control of it? Get in touch.