Sommaire7
L’essentiel
En trente secondes- EnjeuUne caisse de congés payés verse les indemnités des salariés : chaque demande doit lui parvenir complète, chiffrée et validée, sans ressaisie.
- MécanismeUne API NestJS structure les périodes de congé et échange des fichiers par SMB avec le système existant ; Vue 3 porte la saisie.
- PreuveUn an de contributions à l’API et à l’interface, de novembre 2024 à novembre 2025, et un audit de l’application en octobre 2025.
- ImpactChaque demande a un statut et un circuit identifiables, et l’application s’insère dans les échanges de fichiers existants au lieu de les doubler.
- LimitesJ’ai contribué au sein d’une équipe d’au moins cinq développeurs ; je ne revendique ni la direction ni la conception d’ensemble.
- Client
CICP2R- Mon rôle
- Développeur full-stack, contributeur
- Cadre
- Via un partenaire
- Équipe
- Intégré à une équipe existante · 5 personnesAu sein d’une équipe d’au moins cinq développeurs.
- Technologies
NestJS- Vue.js
Pinia
TypeScript
- Liens
Le point de départ
CICP2R est une caisse de congés payés : une association loi 1901 fondée en 1937 par des employeurs, placée sous le contrôle du ministère du Travail, qui verse aux salariés leurs indemnités de congés payés. Pour qu’elle paie juste, chaque demande doit lui arriver avec ses périodes, ses jours à payer et, le cas échéant, la sortie du salarié.
La gestion des congés concentre beaucoup de petites frictions : une demande transmise par un canal, validée par un autre, puis reportée à la main. Chaque étape est simple ; leur enchaînement l’est beaucoup moins.
Ce que j’ai construit
J’ai travaillé sur l’API comme sur l’interface, au sein de l’équipe projet. L’application recueille les demandes, structure les périodes de congé et les conserve avec chaque demande, puis les fait passer par une validation avant export.
Côté serveur, l’API NestJS échange des fichiers avec le système existant par transfert SMB : l’application s’inscrit dans le circuit déjà en place au lieu d’en créer un second. Côté interface, Vue 3 et Pinia portent la saisie, la grille des demandes et l’état des congés.
Ce que montrent les preuves
Mon travail se lit dans l’historique des deux dépôts, l’API et l’interface, sur un an1. En octobre 2025, un audit de l’application a documenté son fonctionnement réel2 : stockage des périodes, circuit de validation, gestion de l’état côté interface.
Historique Git : 33 commits sur l’API…
Historique Git : 33 commits sur l’API et 60 sur l’interface, de novembre 2024 à novembre 2025. Un nombre de commits ne mesure ni l’effort ni la qualité.
Notes d’audit d’octobre 2025 : stockage des…
Notes d’audit d’octobre 2025 : stockage des périodes de congé en JSON, circuit de validation, store Pinia dédié aux congés. Elles ne sont pas publiées, car elles citent des données personnelles.
Les captures ci-dessous viennent d’une instance locale de l’application, alimentée par des données fictives.
Ce que cela change
Chaque demande a un statut et un circuit identifiables, de la saisie à l’export. L’échange de fichiers avec le système existant évite une double saisie entre l’application et la caisse.
J’en retiens qu’un outil RH n’est utile que s’il épouse le circuit réel de l’organisation. La technique compte moins que la justesse de ce circuit et la qualité des échanges avec le système qui paie.
Limites
- Ma part est celle d’un contributeur : d’autres développeurs ont écrit une large part de l’interface.
- Aucun indicateur d’usage n’est disponible : volume de demandes, nombre d’employeurs, délais.
- La cible exacte de l’échange SMB et la date de mise en service restent à confirmer.
- Les documents du projet contiennent des données personnelles : rien n’en est repris ici, et les captures sont réalisées sur des données fictives.
Partager et réutiliser
Le lien, le texte brut et des visuels prêts pour LinkedIn.
