Réseau Grandir Ensemble : une application Shiny reprise, maintenue par son auteur

Client
Réseau Grandir Ensemble, suivi des enfants vulnérables en Pays de la Loire
Période
Octobre 2025 à février 2026
Besoin
Ouvrir un outil interne à 300 médecins et le maintenir sans prestataire
Ce qu'on a fait
Un audit écrit, le code repris sans tout réécrire, trois séances de mentorat
Résultat
En production en janvier 2026. En août, le client assure lui-même la maintenance.
Photo de Abdulai Sayni sur Unsplash

Le client et le contexte

Le Réseau Grandir Ensemble suit les enfants vulnérables des Pays de la Loire, nés prématurés ou avec une pathologie sévère, de la naissance à leurs sept ans. Environ 300 médecins référents assurent les consultations, avec l’appui d’une équipe de coordination d’environ cinq personnes.

Ghislain Leduc, l’épidémiologiste du réseau, avait écrit lui-même une application Shiny pour cette équipe. On y saisit l’adresse d’une famille, et une carte montre les professionnels du réseau les plus proches. L’équipe s’en servait depuis plus d’un an.

Le problème

Le réseau voulait ouvrir cet outil aux médecins référents, et l’application n’était pas prête. L’accès reposait sur quelques mots de passe gérés à la main, et l’hébergement gratuit donnait des temps de chargement trop longs.

Le cahier des charges posait une autre condition. Une fois l’outil livré, le réseau devait pouvoir assurer lui-même la maintenance, l’hébergement, la gestion des utilisateurs et les développements suivants. Il demandait d’ailleurs deux devis, l’un pour faire développer l’application, l’autre pour former son épidémiologiste à le faire. Le réseau a retenu le premier sans renoncer à cette condition : il nous fallait livrer une application que Ghislain saurait reprendre.

La refonte de l’interface, menée dans le même projet, fait l’objet d’une autre étude de cas.

Ce qu’on a fait

Lire le code avant de décider. Avant de décider quoi refaire, on a audité le code. Le réseau a reçu un livrable qui passe en revue l’organisation du code, l’authentification, les tests et le déploiement, avec un constat et une recommandation par sujet. Il conclut : « L’application actuelle ne sera pas réécrite intégralement. »

On a donc gardé ce qui fonctionnait, c’est-à-dire les calculs de distance, la carte, les traitements de données, le stockage en fichiers et le suivi des versions de packages avec renv. Et on a refait ce qui empêchait d’ouvrir l’outil aux médecins. L’authentification est passée à Auth0, avec des droits différents pour la coordination et pour les médecins, et l’application a quitté l’hébergement gratuit pour un serveur loué par le réseau. Le code, lui, a été découpé en modules courts, écrits selon des conventions qu’un contrôle automatique vérifie.

Tout installer chez le client. Le réseau devait assurer lui-même la maintenance et l’hébergement. Le code est donc resté dans le dépôt GitHub d’origine, et c’est là qu’on a livré notre travail. Quand une modification y arrive, une pipeline contrôle le code, construit l’application et la déploie sur le serveur du réseau. Un test de bout en bout accompagne l’application.

Former celui qui reprend. La documentation et le mentorat figuraient au contrat au même rang que le développement. On a écrit un guide de maintenance du serveur et tenu trois séances de mentorat, enregistrées pour que Ghislain Leduc puisse les revoir. Les deux premières portaient sur l’architecture du code, puis sur le déploiement et le serveur.

La difficulté : le même écran copié trois fois

L’application d’origine avait trois pages, pour les médecins référents, pour les professionnels paramédicaux et pour les structures. Chaque page avait sa carte, sa liste et ses filtres, et le code de chacune reprenait celui des deux autres avec quelques variantes, si bien qu’une correction devait être faite trois fois.

Regrouper ce code demandait d’abord de le lire bloc par bloc, pour comprendre ce qui dépendait de quoi. Dans une application Shiny, un calcul se relance quand une valeur dont il dépend change, et ces liens ne sont écrits nulle part.

On a ensuite réuni ce code dans un seul module, que l’application appelle trois fois avec un paramètre différent. Une correction se fait désormais à un seul endroit.

Les résultats

L’application a été mise en recette cinq semaines après le lancement, et elle est en production depuis janvier 2026. Quelques mois plus tard, Ghislain Leduc nous confirmait qu’elle était déployée auprès du réseau et qu’elle ne posait aucun problème.

Le réseau voulait maintenir l’application sans prestataire, et c’est ce qu’il fait. Sept mois après la mise en production, Ghislain Leduc a mené seul sa première maintenance, en mettant à jour R et tous les packages de l’application. Il nous avait demandé de rester joignables au cas où, et il nous a peu sollicités.

Cette mise à jour a pourtant posé un problème, comme il arrive souvent quand on change de version de R : l’application ne se construisait plus. La pipeline a alors joué son rôle. Elle a refusé de déployer la nouvelle version, et les médecins ont continué à utiliser celle qui était en ligne. Ghislain Leduc a trouvé la cause lui-même, et la version corrigée était en production moins de deux heures plus tard.

Il continue à développer en Shiny, et il nous a demandé conseil pour une nouvelle application qu’il écrit.

Dans son témoignage, Ghislain Leduc retient « la pédagogie dont vous avez su faire preuve » et cite l’audit, « qui, au-delà de poser les bases de ce que vous alliez faire, était aussi pour moi un gros levier d’amélioration, très utile à l’avenir ». Il y parlait aussi de la suite : « il y a un certain nombre de développements que je serai probablement en capacité de faire moi-même ».

Vous avez une application Shiny écrite en interne à faire passer en production, et vous voulez en garder la main ? Écrivez-nous.

Commentaires

Laisser un commentaire

Les champs obligatoires sont marqués d'un astérisque *

Markdown accepté

Les commentaires sont validés manuellement.
La page va se rafraîchir après envoi.