Étude de cas
Portail RH unifié multi-agences
Centralisation des données collaborateurs pour un groupe industriel
- Angular
- Java
- Spring Boot
- TypeScript
- PostgreSQL
Contexte entreprise
Ortec Group est un groupe français de services à l'industrie et à l'environnement, employant plus de 14 000 collaborateurs dans le monde, dont le siège est basé à Aix-en-Provence.
Problématique
Les données RH étaient dispersées entre de nombreux outils et agences, rendant le suivi des collaborateurs complexe, chronophage et sujet aux erreurs.
Solution apportée
J'ai participé au développement d'un portail RH unifié centralisant les données collaborateurs pour l'ensemble des agences du groupe :
- Filtres dynamiques et recherches avancées.
- Tableaux interactifs pour l'analyse des données.
- Modules métiers : suivi des EPI, visites médicales, expositions CMR, accès sites et habilitations / formations.
Résultats
- Centralisation des données pour toutes les agences.
- Gains de temps significatifs pour les équipes RH.
- Fiabilité et traçabilité accrues des processus réglementaires.
Équipe & méthode
- Équipe de 6 développeurs, 1 product owner et 1 architecte technique.
- Méthodologie Agile (Scrum) avec des sprints de 3 semaines.
- Revues de code systématiques et intégration continue.
Stack technique
Java, Angular, Spring Boot, TypeScript, PostgreSQL, Docker, Git.
01
Contexte et enjeu
Ortec Group suit la conformité de ses collaborateurs sur l'ensemble de ses agences : équipements de protection individuelle, visites médicales, expositions aux agents CMR, accès aux sites, habilitations et formations.
Les données étaient suivies agence par agence, sans vision consolidée ni échéancier commun : un risque de conformité et une charge de suivi importantes pour les équipes.
02
Mon rôle et périmètre
Développement front-end des cinq modules métier en Angular et TypeScript : filtres dynamiques, recherches avancées et tableaux interactifs.
Traitement de la performance des écrans les plus sollicités (volumétrie élevée, filtres combinés) et des règles d'accès aux données selon le profil.
Consommation des API REST exposées par le back-end Java / Spring Boot.
03
Défis techniques
Consolider des données multi-agences
Le suivi existait agence par agence : le portail devait offrir une vue unifiée par collaborateur, filtrable et exploitable, sans imposer la même organisation à chaque agence.
Rendre lisibles des échéances réglementaires
Visites médicales, habilitations et formations ont chacune leurs échéances : il fallait les rendre visibles et actionnables, sans noyer l'utilisateur sous les alertes.
Tenir la performance sur des tableaux volumineux
Sur des listes de collaborateurs et d'échéances à forte volumétrie, les filtres dynamiques et les recherches avancées devaient rester utilisables : le travail se joue autant sur les requêtes et la pagination que sur l'affichage.
04
Solution et architecture
05
Stack détaillée et pourquoi
- Angular
- Pourquoi ce choix — Framework structurant (modules, injection de dépendances, formulaires réactifs) : adapté à une application métier riche, avec de nombreux écrans de saisie et de filtrage à maintenir dans le temps.
- Java / Spring Boot
- Pourquoi ce choix — API REST typée sur un écosystème Java mature, outillé pour la persistance, la sécurité et les tests — le socle attendu pour un applicatif de gestion.
- PostgreSQL
- Pourquoi ce choix — Données métier très relationnelles (collaborateurs, sites, équipements, habilitations, échéances) : le modèle relationnel et ses contraintes font le travail de cohérence.
06
Résultats
- Modules fonctionnels livrés
- 5EPI, visites médicales, expositions CMR, accès sites, habilitations et formations
07
Ce que j'en retiens
Un portail de conformité se joue moins sur l'affichage que sur la hiérarchisation : rendre une échéance utile, c'est d'abord choisir ce qu'on montre en premier. Le vrai travail a été de transformer cinq suivis menés agence par agence en une lecture unique et filtrable, sans perdre l'information dont chaque agence a besoin au quotidien.