Le client et le contexte
La FNTP est la Fédération Nationale des Travaux Publics. En 2025, on a développé pour elle une application qui transforme les statistiques d’accidents du travail de la CNAM en articles de prévention. Le produit a sa propre étude de cas.
Côté client, un groupe de travail suivait le projet. Il réunissait la Fédération, des organismes de prévention et des entreprises de travaux publics. Damien, consultant indépendant (DM Conseil), portait la mission auprès de la FNTP et nous avait confié le développement.
Avant le premier jour de développement, la FNTP avait déjà fixé la date de livraison et le calendrier des points de suivi, un toutes les deux semaines.
Le problème
Au lancement, plusieurs sujets restaient ouverts : le format de sortie des articles, la façon de les publier, l’hébergement, le stockage des données. L’agent IA reposait sur ellmer et shinychat, deux packages R qu’on n’avait jamais utilisés.
Chaque présentation de l’application au groupe de travail amenait de nouvelles demandes. Il fallait les traiter toutes les deux semaines sans déplacer la date.
Ce qu’on a fait
Une fiche de suivi avant chaque point. Une réunion de suivi commence souvent par un long moment où le prestataire raconte ce qu’il a fait. Avec un point toutes les deux semaines et un groupe de travail à mettre d’accord, on voulait que ce temps serve à décider.
Dès la première semaine, on a donc découpé le projet en tickets dans OpenProject, notre outil de gestion de projet. Avant chaque point, Léo en tirait une fiche d’une page avec le planning semaine par semaine, où l’on voit ce qui était prévu, ce qui a été fait et ce qui a été décalé, puis l’avancement de chaque lot, les prochaines étapes et une rubrique pour les risques et les décisions à prendre.
Sur cette capture, les noms du chef de projet et du contact client ont été remplacés.
Comme la fiche arrive avant la réunion, celui qui la reçoit sait déjà où en est le projet quand la séance commence, et on passe directement aux arbitrages. C’est aussi par elle que les mauvaises nouvelles arrivent tôt. Quand les demandes du groupe de travail ont commencé à s’ajouter au périmètre, la rubrique des risques l’a signalé alors qu’il restait sept semaines pour en tenir compte.
Un compte rendu qui répond à chaque demande. Le groupe de travail découvrait l’application à chaque point, et chaque démonstration lui donnait de nouvelles idées. À la livraison, une trentaine des 57 fonctionnalités venaient de ces demandes. Or la date était fixée et l’enveloppe budgétaire aussi, si bien que chaque demande acceptée telle quelle prenait du temps sur ce qui était déjà prévu.
On a donc cherché, pour chaque demande, le besoin qu’elle exprimait et la façon la moins coûteuse d’y répondre. La réponse partait par écrit dans le compte rendu, en général dès le lendemain du point. Elle disait si la demande serait développée telle quelle, remplacée par une solution plus simple ou gardée pour une version ultérieure. La FNTP savait ainsi, avant le point suivant, ce que chacune de ses demandes allait devenir.
Quand le groupe a voulu afficher plusieurs graphiques dans un même contenu, on lui a proposé de dupliquer un contenu pour retravailler la copie avec un autre graphique, une fonction bien plus rapide à développer. Quand il a voulu corriger un article déjà publié, on a présenté deux options et retenu ensemble la plus simple, qui consiste à le corriger directement dans WordPress, où l’éditeur est plus complet.
La discussion prenait parfois plus d’un tour. La FNTP a demandé des graphiques interactifs dans les articles publiés, et on a expliqué dans le compte rendu pourquoi on ne le ferait pas : l’application et le transfert des articles vers WordPress en seraient devenus très lents. Comme la Fédération y tenait, elle nous a demandé de lui proposer autre chose. On a alors placé l’interactivité dans l’application, avec un onglet « Tableau de bord » où l’utilisateur explore lui-même les données de sinistralité.
La difficulté : un choix de stockage à rouvrir
Le stockage des données figurait dans notre liste de questions au cadrage. On ne l’a pas tranchée à ce moment-là, et on a commencé à développer avec PostgreSQL, notre choix habituel.
C’est en développant qu’on a vu qu’une base relationnelle convenait mal à ce que l’application devait ranger. Un contenu regroupe une conversation avec l’agent, un tableau, un texte et l’image d’un graphique, et la base de connaissance est faite de documents PDF. L’application manipule donc surtout des fichiers.
On a inscrit le sujet dans la rubrique des risques de la fiche de suivi avant d’avoir une solution, pour que le client soit au courant sans attendre. On a ensuite passé en revue avec lui les alternatives et ce que chacune risquait, par exemple quand deux utilisateurs écrivent en même temps, et la décision s’est prise ensemble. Les données sont stockées dans Azure Blob, le service de stockage de fichiers de Microsoft, auquel l’application accède avec le package R AzureStor. Le changement était terminé avant la livraison.
Les résultats
Le périmètre a grandi d’une trentaine de fonctionnalités, toutes menées à terme, et la date n’a pas bougé. L’application a été livrée quatorze semaines après le démarrage, au jour que la FNTP avait fixé avant le début du développement.
Les utilisateurs désignés par la FNTP l’avaient entre les mains dès la fin août, ce qui leur a laissé le temps de la tester et de faire remonter leurs remarques avant la livraison.
Neuf mois plus tard, Damien nous confirmait que la Fédération s’en servait toujours.
Vous avez un projet avec une date imposée et un périmètre encore ouvert ? Écrivez-nous.
Commentaires