Temps de lecture estimé : 12 minutes
Une société en croissance doit adapter son Système d’Information : ses besoins évoluent, elle doit donc mettre en place de nouveaux outils de gestion.
L’intégration aux logiciels déjà présents est essentielle : les collaborateurs ne perdent pas de temps en double saisie, mais surtout, on diminue le risque d’erreur, et ainsi les processus métier sont alimentés avec des données de qualité.
Ce cas d’usage décrit comment Kaizen Solutions a intégré un nouvel outil RH, dans le cadre d’un projet interne, en appliquant les méthodes et outils qui avaient été déployés il y a un an.
Le problème : ERP existant, SIRH à intégrer
Pour assurer la gestion des données des collaborateurs, des clients et des projets, Kaizen Solutions utilise un Entreprise Resource Planner (ERP), qui répond depuis de nombreuses années aux fonctionnalités cœur du métier d’Entreprise de Service Numérique (ESN).
La croissance amène cependant la nécessité d’améliorer la gestion des temps et des absences (GTA), pour alléger un processus RH cœur, et Kaizen Solutions a donc contractualisé un nouvel outil dédié, de la catégorie Système d’Information des Ressources Humaines (SIRH).
Si ce nouvel outil apporte tout un tas de bonnes choses, il ne vient
hélas pas avec un connecteur pour notre ERP actuel ; celui-ci reste en
place pour gérer nos prestations, et doit donc connaître les absences
pour permettre les imputations et la facturation des projets.
La question est donc : comment synchroniser des absences de l’outil de Gestion des Temps vers notre ERP ?
La réponse, version courte
les deux outils sont des services webs (Software as a Service, SaaS) avec des interfaces de programmation (Application Programming Interface, API) ; l’équipe Projet SI de Kaizen Solutions a donc simplement développé un composant de synchronisation :
L’histoire est évidemment un peu plus longue, mais avec l’utilisation de SnapLogic, notre outil d’intégration d’application, rien de compliqué : c’est ce qu’on va vous présenter !
Le contexte
Dans un épisode précédent
Notre ERP est satisfaisant pour la gestion générale, mais il apparaît nécessaire de mettre en place des outils type Système d’Information des Ressources Humaines (SIRH), en commençant par un module de gestion du temps et des absences (GTA).
En préalable, les étapes suivantes ont été réalisées pour s’assurer que l’on saura répondre au besoin :
- ✅ Recueil du besoin côté Direction des Ressources Humaines
- ✅ Analyse du marché des éditeurs de solutions SIRH
- ✅ Sélection du meilleur candidat
- ✅ Réalisation d’un PoC, pour vérifier que l’on saura s’interfacer avec notre ERP
On a donc contractualisé début juin 2023, et c’est parti pour le développement ! 🚀
Parties prenantes
- La Direction des Ressources Humaines : pour outiller la gestion du
temps, en particulier des absences, grâce à l’introduction d’une
nouvelle solution
- La Direction Finance, ainsi que les équipes Commerce et projets :
pour suivre les projets dans l’ERP, avec les rapports existants
- La Direction des Opérations : développe et opère le Système d’information
Le besoin
L’équipe des Ressources Humaines, avec l’aide de notre analyste
fonctionnelle, a rédigé la spécification, en suivant les axes
habituels :
- fonctionnel : synchronisation des absences validées ou annulées, en faisant la correspondance des compteurs d’absences,
- configuration : paramétrage de la configuration, utilisation de comptes de service,
- performance : objectif de nombre de collaborateurs, de temps de réponse,
- suivi : export de suivi des demandes.
Ceci s’est traduit en exigences de conception et d’architecture :
- pour organiser le développement
- en clarifiant les étapes de traitement : préparation, extraction, transformation, publication
- en formalisant les interfaces entre les étapes, limitant au maximum
les adhérences aux API externes, pour permettre un développement en Test-Driven Design (TDD) avec une couverture maximisée par des tests automatiques
- pour assurer la performance, en identifiant les données devant être
précalculées, notamment la table de correspondance des collaborateurs
- pour assurer la supervision
- enregistrement des requêtes et des résultats
- comparaison des absences entre les deux bases
- et présentation dans un rapport Power BI de suivi
Le planning
La mise en production du SIRH est prévu en janvier 2024, soit 6 mois
pour faire la mise en place ; pour l’éditeur et l’équipe RH, c’est le
temps nécessaire pour faire la spécification, le paramétrage, la recette
puis la phase d’import en masse.
Le développement du composant de synchronisation s’est fait en parallèle, sans impact sur le planning.
Les détails de l’implém’ et son architecture
Connecter les éléments
Comme on l’a vérifié dans le PoC, tous les composants du problème peuvent être connectés de manière native :
- le SIRH-GTA dispose d’un module de synchronisation, pour déclencher
un traitement lors d’une approbation ou une annulation d’absence
(techniquement, un webhook) ;
- l’ERP permet de créer, valider et annuler des absences via son Application Programming Interface, API ;
- Kaizen Solutions dispose de SnapLogic, un outil d’intégration de données et d’applications, et les traitements peuvent être déclenché via un appel à son API.
Ce dernier point est vraiment important : lorsque Kaizen Solutions a sélectionné SnapLogic comme outil Extract, Transform, Load (ETL),
le déclenchement de traitements via API avait été identifié mais pas
comme un critère essentiel. SnapLogic implémente cela de manière native,
ce qui nous a permis d’élargir vraiment le champ des usages, et cette
fonctionnalité nous est aujourd’hui incontournable. SnapLogic permet
donc bien plus que l’acronyme ETL le laissait supposer, et est
réellement une plateforme d’« intégration d’applications ».
Bref, on sait travailler à la demande, on peut partir sur une conception événementielle :
dès qu’une absence est validée ou annulée, le module GTA déclenche un
traitement dans SnapLogic, qui créée ou annule l’absence correspondante
dans l’ERP.
En pratique, le module GTA gère une queue d’événements, la tâche
SnapLogic est une tâche basique, bref la synchronisation prend quelques
minutes, ce qui est normal au vu des ressources mutualisées et du nombre
de composants dans la chaîne.
Donc pas besoin d’attendre la nuit pour qu’une synchronisation de type batch tourne, “années 90-style”, ce qui apporte un vrai confort à l’utilisation.
Traduire les données
Le webhook du SIRH émet donc des changements ; reste à assurer la traduction vers le modèle de données de l’ERP.
En première approche, les structures sont comparables :
- une période d’absence est liée à un motif (Congé Payé, RTT…) ;
- une période d’absence est une période contigüe, avec une granularité à la demi-journée ;
- une période d’absence a un statut de validation, par le manager ou autre,
- les collaborateurs portent un matricule unique.
Quelques surprises cependant :
- Le webhook émet quand une période d’absence est validée ou annulée, mais avec un événement par demi-journée contenue dans la période d’absence ! Ce qui démultiplie le nombre de requêtes, et contraint à l’efficacité.
- Les motifs d’absence sont structurés de manière légèrement
dissimilaire, le SIRH permettant de gérer finement les congés sur base
annuelle (CP, RTT) et l’ERP non.
- Le circuit de validation d’une absence dans l’ERP dépend du profil associé au collaborateur.
- L’ERP ne permet pas de saisir des absences sur des jours non ouvrés,
ce qui pourtant a bien un sens pour le SIRH, par exemple pour les
absences maladie.
Ce qui amène une architecture du projet dans SnapLogic en deux temps :
- Chaque jour, un traitement planifié :
- extrait la liste des collaborateurs, et construit la table de correspondance entre SIRH et ERP,
- extrait la liste des jours considérés comme ouvrés par l’ERP,
- enregistre le tout dans notre base de donnée interne.
- À chaque appel par le webhook du SIRH, un second traitement :
- récupère les correspondances de collaborateur et de motif d’absence via la base de données,
- vérifie si l’absence est sur un jour ouvré ou non,
- émet les requêtes vers l’ERP pour créer/valider, ou annuler,
- enregistre les événements dans notre base de données.
Et la sécurité des données ?
Les connexions se faisant entre plateformes SaaS sur internet, elles
sont toutes exposées au public ; du coup, pour le volet
Confidentialité :
- Tous les échanges sont faits via des connexions sécurisées, par exemple en https ;
- Tous les échanges sont authentifiés, via des comptes de service
disposant de droits minimum, avec une attention particulière aux droits
en modification, et seuls les administrateurs du SI ont accès à ces
comptes de service ;
- Le serveur d’exécution est dans notre infrastructure, et SnapLogic n’enregistre que les métadonnées ;
- La base de données n’est pas accessible d’internet, et seuls les administrateurs du SI y ont accès ;
- Les droits d’accès aux documents générés sont faits par les administrateurs du SI ;
- Avant déploiement en production, le projet est revu par le
Responsable de la Sécurité du Système d’Information (RSSI), qui est
également signataire du PV de recette (en plus de l’approbation métier).
Concernant les autres volets classiques de la sécurité de l’information, DICT :
- Disponibilité : le SIRH, l’ERP et SnapLogic ont des clauses de
disponibilité qui correspondent au besoin fonctionnel, et notre
supervision permet de vérifier le bon fonctionnement du composant de
synchronisation.
- Intégrité, Traçabilité : via la supervision, le composant de
synchronisation propose des moyens de contrôle des données et des
journaux d’exécution, cf. infra.
Pour le développement, on utilise des environnements dédiés, avec des
instances du SIRH, de l’ERP, de SnapLogic et de la base de données, qui
sont spécifiques et ne contiennent que des données factices. Cela
permet d’explorer les cas usages et de robustesse, de développer puis de
tester sans risque pour la continuité et l’intégrité des données de
production.
Quelques cas de robustesse
Comme le système est distribué, les cas de robustesse suivants sont à considérer :
-
déconnexions diverses :
- échec de déclenchement du traitement dans SnapLogic, par exemple
lors d’une maintenance de la plateforme SnapLogic ou du serveur
d’exécution,
- time-out du retour de traitement vers le SIRH, alors que le traitement a bien fonctionné.
Dans le premier cas, il faut pouvoir relancer le traitement qui n’a
pas démarré (automatiquement c’est encore mieux), ou pouvoir identifier
le traitement incomplet pour le terminer manuellement. Dans le second
cas, il faut gérer le doublon éventuel, ce qui est assez facile vu que
les absences sont immuables.
-
incohérences entre les outils :
- correspondance manquante entre les collaborateurs, par exemple sur faute de frappe d’un matricule,
- configuration des compteurs d’absence différents.
La correction ne peut être automatique, il faut donc une visibilité
sur ces défauts pour qu’une action correctrice soit possible. Il est
ensuite intéressant de pouvoir relancer manuellement la synchronisation,
pour vérifier que la situation est bien corrigée.
Pour assurer les opérations
Assurer la supervision
Les outils sont maintenant connectés, c’est bien ! Mais comment s’assurer que :
- tout fonctionne correctement ?
- en cas de dysfonctionnement, on est capable d’identifier la cause du problème ?
Hélas, pas de solution miracle : les traitements événementiels ne
sont pas de minces affaires. En s’inspirant de ce qui se fait dans
l’aéronautique et autres environnements critiques, on mise sur
différents aspects :
- D’abord, des tests complets (la base !), automatiques ou non, pour
prouver que tout fonctionne correctement, y compris la gestion des cas
de robustesse anticipés.
- Pour les cas non-identifiés (il y en a toujours !), où par définition
on ne sait pas ce qui va se passer, il faut penser “boîte noire” (celle qui est orange, pas celle du test logiciel) pour permettre une analyse post-mortem :
- enregistrement des données des requêtes entrantes, en y attribuant un identifiant unique,
- enregistrement des données en sortie de chaque traitement, notamment le statut OK/KO, associé à l’identifiant de la requête,
- enregistrement par un traitement “capsule”, garantissant l’écriture
des données même si une étape du traitement rencontre un échec critique.
-
Pour détecter une éventuelle interruption de service, notre système
de supervision vérifie en continu que les exécutions ont bien été
démarrées et qu’elles n’ont pas échoué.
-
Pour détecter une éventuelle corruption, une comparaison des absences
est faite chaque jour entre les deux outils, en utilisant une chaîne
indépendante :
Les données de traitement et le résultat des surveillances est affiché
dans un rapport Power BI, mis à disposition des utilisatrices (eh oui,
aucun humain mâle n’est aux manettes !). Ce tableau de bord leur permet
de visualiser l’état de la synchronisation et les écarts éventuels.
En bonus, un diagramme affiche des statistiques sur les temps de
traitement, rendant ainsi visible d’éventuelles dérives de performance.
Assurer que toutes les absences sont synchronisées
On s’est donc assuré d’avoir connaissance des écarts, mais comment les gérer ?
Le webhook du SIRH maintient un journal de synchronisation,
qui affiche le résultat de chaque requête, et ô joie : les événements en
échec sont retentés de manière automatique ! Les utilisatrices peuvent
donc visualiser les traitements ayant échoué, et même relancer
directement des traitements échoués de manière manuelle.
Donc pas besoin d’implémenter la logique de réessais dans le cadre de notre intégration.
Recette et déploiement
Pour préparer la remise des clés du composant de synchronisation aux
RH, des démonstrations ont été faites au cours du développement :
- pour présenter le fonctionnement et le paramétrage du composant de synchronisation ;
- pour présenter le rapport de suivi, les infos qui y sont disponibles, et la gestion des cas dégradés ;
- pour valider que les cas d’usages identifiés sont bien pris en charges… et en identifier de nouveaux !
Une fois les usages consolidés, la version 1.0.0 a été finalisée et déployée en production.
De tout cela, quelques apprentissages :
- Il est essentiel de lister les profils utilisateurs dans chaque
outil, et de s’en servir dans chaque test, pour s’assurer que les
requêtes du composant de synchronisation respectent bien les règles
métier. Ce qui a amené à la version 1.0.1, le lendemain de la recette…
- La doc des API laisse parfois des tournures interprétables. Des
essais permettent de constater l’existant, mais attention à ce que
l’intégration ne “tombe pas en marche” !
- Il ne faut donc pas hésiter, en amont de la finalisation d’une
version, à contacter l’éditeur de l’API pour lever les ambigüités, et
ainsi éviter des évolutions non attendues à l’avenir.
- Il faut rester attentifs à l’utilisation en production, pour
identifier les défauts et les usages non anticipés, et proposer des
manières de les gérer au mieux.
Pour conclure
En termes techniques, c’est une réussite : au 1ᵉʳ mars 2024, 13248
événements ont été synchronisés, les cas d’usage sont gérés avec très
peu de palliatifs manuels. Seulement quelques bugs ont été observés, qui
ont été corrigés sans remise en cause de l’architecture, et déployés
sans interruption de service.
Pour Kaizen Solutions, c’est aussi une réussite projet :
- La synchronisation a été développée en parallèle du déploiement de
l’outil SIRH, et a été au rendez-vous à la mise en production.
- La petite équipe Projet SI a bien fonctionné : une analyste
fonctionnelle pour comprendre les utilisatrices, formaliser le besoin et
définir les jeux de test, plus un développeur pour concevoir la
solution et l’implémenter… et ça suffit 💪
- Il y a quelques mois, le seul traitement de comparaison des absences aurait constitué un projet en lui-même !
- Les ressources ont été disponibles et pertinentes : la plateforme
SnapLogic répond au besoin, nos outils SaaS sont accessibles et
documentés, et les éditeurs ont été disponibles et compétents pour
supporter cette intégration.
Retour aux articles