Mission client · 2021 – 2024 · Tech Lead Fullstack
SNCF DGEX Solutions
Du roulement au planning des agents
Deux plateformes RH : architecture, règles métier et déploiements Kubernetes.
Première version en moins de six mois · gain de temps estimé : environ 90 % face à la préparation manuelle
Résumé
- Problème
- Construire des roulements conformes aux règles RH, jusque-là préparés sur papier.
- Rôle
- Tech Lead Fullstack : architecture, développement, tests, déploiements et accompagnement des développeurs.
- Solution
- Deux plateformes Angular / Node.js et un modèle métier partagé, relié à un moteur d’optimisation externe.
- Résultat
- Première version livrée en moins de six mois et adoptée par les équipes métier.
- Limite
- Les calculs peuvent durer plusieurs minutes. Leur exécution asynchrone restait une évolution envisagée.
Le besoin des services RH
Les services RH avaient besoin de simplifier la préparation des roulements et des plannings. Ce travail demandait de concilier les besoins de service avec de nombreuses règles de travail et de repos, destinées à garantir de bonnes conditions de travail aux agents. La préparation manuelle des roulements sur papier rendait cette tâche longue et complexe.
Le roulement définit un cycle de services et de repos pour un groupe d’agents. Le planning applique ce cycle au calendrier, avec les absences, les remplacements et les habilitations.
Deux applications ont été développées pour répondre à ce besoin : la première permet de construire et de comparer des roulements ; la seconde les utilise pour préparer les plannings. Le travail avec les équipes métier a permis de formaliser les règles de conformité, puis de les intégrer aux outils de saisie, de vérification et de calcul.
La mission a démarré avec un seul développeur, puis l’équipe s’est agrandie jusqu’à quatre personnes. L’accompagnement technique reposait sur la programmation en binôme et la documentation.
L’architecture des deux plateformes
Un modèle métier partagé
Les modèles métier, les règles de conformité et les contrats d’API sont regroupés dans un paquet TypeScript distribué comme module Node.js. Ce module est utilisé par les interfaces Angular et les API. Les mêmes vérifications s’appliquent dans le navigateur et côté serveur, avec un signalement des erreurs pendant la saisie.
Le développement de la seconde application a impliqué de généraliser les modèles de grille et d’activité. Le planning réutilise ainsi les outils de vérification du roulement, avec ses propres règles sur les habilitations et les horaires.
Les applications et le moteur externe
Chaque plateforme associe une interface Angular à une API Node.js / LoopBack. Les roulements sont stockés dans MongoDB, les plannings dans PostgreSQL.
Le moteur d’optimisation était fourni par un prestataire. Son intégration a nécessité une couche de traduction entre les données métier et le format attendu par le moteur. L’API prépare les contraintes du calcul ; un service séparé exécute le moteur et renvoie le résultat.
Interface Angular
API Node.js / LoopBack
MongoDB
Interface Angular
API Node.js / LoopBack
PostgreSQL
Flux d’optimisation des roulements
- ProjetServices, besoins et paramètres
- APITraduction en contraintes et objectifs
- ServiceAppel au moteur et lecture du résultat
- PrestataireMoteur d’optimisation externe
Le résultat revient dans l’application sous forme de grille, avec ses indicateurs et ses erreurs.
Le moteur de règles
Les règles vérifient les enchaînements de services, les durées de travail et les repos. Elles tiennent compte du caractère cyclique des roulements : la fin de la grille rejoint son début.
Le moteur d’optimisation ne connaît pas les règles métier. Il faut lui indiquer quels services peuvent se suivre et quels enchaînements sont interdits. Pour les règles de repos, le système teste les combinaisons avec le moteur de règles métier, puis transmet les interdictions au moteur d’optimisation.
Les règles utilisées pour vérifier les roulements saisis servent ainsi à préparer le calcul. Les autres contraintes viennent des paramètres du projet et du régime de travail.
Après le calcul, un algorithme place les repos complémentaires et les disponibilités. La douzaine de règles de placement a été précisée avec l’équipe métier avant son implémentation.
Le moteur peut renvoyer une solution partielle, signalée dans l’interface. Les données échangées restent consultables pour analyser un échec avec le prestataire.
Développement et déploiements
Ajuster les plannings au quotidien
Les équipes RH peuvent modifier les activités prévues pour un agent. L’application ajuste les horaires des activités concernées et recalcule ses compteurs : ces informations restent à jour pendant les modifications. Un historique permet d’annuler une modification ou de la rétablir.
Les données des agents et les activités déjà planifiées peuvent être importées depuis les fichiers Excel des systèmes existants. L’import vérifie leur contenu et signale les erreurs à corriger.
Des builds aux déploiements Kubernetes
La livraison repose sur des pipelines Jenkins et des déploiements Ansible / Helm sur Kubernetes chez AWS. Leur mise en place s’est appuyée sur les outils internes du client et sur l’équipe qui les maintenait.
Le pipeline publie une archive versionnée, utilisée pour construire l’image Docker. La configuration est injectée au démarrage : une même image sert aux environnements de test, de recette et de production. L’infrastructure était supervisée avec Datadog.
Les tests couvrent les règles métier et les API : 82 % des lignes du modèle partagé, 80 % de l’API des roulements et 89 % de l’API du planning. La publication du paquet partagé est bloquée si un test échoue.
Résultats et limites
La première version de l’outil de roulements a été livrée en moins de six mois et adoptée par les équipes métier. Elle a permis de débloquer un an et demi de budget supplémentaire pour poursuivre le projet.
Le gain de temps est estimé à environ 90 % par rapport à la préparation manuelle. Les outils permettent de gérer les roulements et plannings d’environ 100 000 agents.
Un calcul peut durer plusieurs minutes. L’appel au moteur était synchrone : l’application attendait son résultat. Un traitement asynchrone par file de messages était envisagé pour suivre les calculs et gérer les reprises après échec.