Le client et le contexte
L’Ifremer anime le Système d’Informations Halieutiques (SIH), le réseau national qui observe les ressources de pêche et l’activité des flottilles françaises. Des observateurs collectent les données sur le terrain, en criée, au débarquement ou à bord des navires. Ces données alimentent ensuite la recherche et les avis d’expertise de l’institut.
Avant d’être utilisées, elles sont contrôlées dans Valparaiso, une application R Shiny. Les observateurs y repèrent les anomalies détectées dans leurs propres saisies, puis les coordinateurs de l’Ifremer vérifient l’ensemble. L’application compte cinq volets, parmi lesquels les ventes en criée, les débarquements en outre-mer et les mesures biologiques des poissons.
Le volet Activité donne une idée des volumes. Chaque année, au premier trimestre, une cinquantaine d’observateurs y contrôlent les calendriers d’activité d’environ 6 000 navires. Les autres volets servent toute l’année.
Valparaiso existe depuis 2021. Écrite d’abord par des développeurs de l’Ifremer, puis par un prestataire, elle a fait l’objet en 2025 d’un marché public de maintenance, que nous avons remporté. Depuis septembre 2025 et pour quatre ans, on en assure la maintenance corrective, la maintenance préventive et les évolutions, que l’Ifremer commande trimestre par trimestre.
Le problème
Un audit commandé par l’Ifremer en 2024 avait posé le constat. L’application était devenue difficile à maintenir, et ses utilisateurs signalaient des lenteurs et des plantages. À notre arrivée, le code ne contenait aucun test automatisé.
L’Ifremer cherchait donc une équipe spécialisée en R Shiny, capable aussi d’intervenir sur l’API Java qui relie l’application aux bases de données.
La contrainte venait de l’usage. Valparaiso sert toute l’année, chaque volet selon son propre calendrier de contrôle. Il fallait donc la corriger et la faire évoluer pendant que les équipes s’en servaient.
Ce qu’on a fait
Comprendre avant de modifier. Le marché prévoyait deux mois pour prendre connaissance de l’existant. On s’est rendus à Nantes, où les équipes de l’Ifremer nous ont présenté le SIH et montré chaque volet. On a relu le code R et audité l’API Java, et notre experte UX a mené des entretiens avec six utilisateurs. Ce travail a abouti à un bilan qui décrit l’architecture, les faiblesses du code et les attentes des utilisateurs, avec des préconisations classées par priorité.
Stabiliser avant d’ajouter. Au premier comité de pilotage, nous avons convenu avec l’Ifremer d’un ordre des travaux : le premier trimestre irait aux corrections et à la remise en ordre du code, et les évolutions métier viendraient ensuite. On a donc commencé par réorganiser le code de l’application. Pour s’assurer que rien n’avait changé pour les utilisateurs, l’Ifremer a testé cette version en la comparant à celle en production, volet par volet, avant sa mise en ligne à la fin du trimestre. On a ensuite ajouté des tests automatisés à la chaîne de livraison, qui bloque maintenant une version quand un test échoue.
Livrer souvent, et laisser la production au client. Chaque correction suit le même circuit. On la livre sur un environnement de validation, les référents de l’Ifremer la testent, puis le service informatique de l’institut la met en production. Un point de suivi a lieu toutes les deux semaines, et un comité de pilotage chaque trimestre.
La difficulté : l’écran qui se grise
Parmi les plantages, les utilisateurs décrivaient tous le même. En plein travail, sans avoir rien cliqué, l’écran devenait gris et l’application ne répondait plus, sans aucun message d’erreur pour expliquer ce qui s’était passé.
Faute de message, il fallait chercher la cause par la mesure. On a rejoué des scénarios d’utilisation sur les cinq volets en relevant la mémoire consommée à intervalles réguliers. Les courbes ont montré que l’application gardait en mémoire les données des utilisateurs déjà partis. Elle finissait par atteindre la limite fixée par le serveur, qui l’arrêtait et déconnectait tout le monde. On a donc changé la façon dont l’application est lancée, pour que la mémoire soit rendue quand plus personne n’est connecté.
Ce correctif n’a pas suffi. Le problème est revenu quelques mois plus tard, signalé cette fois par le service informatique de l’Ifremer, et il a fallu une seconde version corrective intégrant des optimisations plus fines dans les traitements de données. L’Ifremer a ensuite constaté beaucoup moins de déconnexions.
Les résultats
Valparaiso a été corrigée pendant que ses équipes s’en servaient. En dix mois, plus d’une douzaine de versions ont été mises en production, chacune testée par l’Ifremer avant sa mise en ligne. Au fil de ces versions, son équipe a vu diminuer la liste des anomalies à corriger.
Le service informatique de l’institut y a gagné aussi. Chaque nouvelle version occupait trop de place sur ses serveurs, et il nous avait demandé de réduire l’image Docker de l’application, qui est passée de 5,7 Go à 2 Go.
Le travail continue sur le volet Activité. Il ne sert que quelques mois par an, si bien que les observateurs doivent être reformés avant chaque campagne. On y a livré une série d’évolutions demandées par sa coordinatrice, et notre designer a repensé le parcours de contrôle, testé sur maquette par trois utilisatrices de l’Ifremer. Cette nouvelle interface doit être en service pour la campagne de janvier 2027.
Vous avez une application R Shiny en production, écrite par d’autres, à maintenir ou à faire évoluer ? Écrivez-nous.
Commentaires