L’intégration de Lucca dans un écosystème RH existant se joue moins sur le choix des modules que sur la manière dont les flux de données circulent entre les systèmes. Avant de parler de déploiement ou de conduite du changement, il faut trancher une question d’architecture : quel système fait foi pour chaque donnée, et comment les synchronisations sont-elles déclenchées.
API Lucca et modes de synchronisation : choisir entre événements et batchs
La documentation de l’API Lucca décrit deux approches pour faire circuler les données. La première repose sur des synchronisations par événements (webhooks) : chaque création, modification ou suppression d’une donnée déclenche un appel vers le système cible. La seconde, plus classique, passe par des extractions périodiques (batchs quotidiens ou hebdomadaires).
Le choix n’est pas anodin. Un webhook garantit une réactivité quasi immédiate, mais impose de gérer les événements manqués ou dupliqués. Un batch est plus simple à superviser, mais introduit un décalage qui peut poser problème pour la paie ou les absences validées en fin de mois.
Avant toute configuration, il faut répondre à cette question : quel délai de propagation est acceptable pour chaque type de donnée ? Les modifications du dossier collaborateur tolèrent souvent un décalage de quelques heures. Les validations d’absences avant clôture de paie, non.
La possibilité d’intégrer un connecteur Lucca aux systèmes RH dépend aussi de la version d’API utilisée. L’API v5 supporte OAuth 2.0, tandis que les versions v3 et v4 fonctionnent avec des clés API historiques. Vérifier la version d’API avant de coder un connecteur évite de bâtir une intégration sur un mécanisme d’authentification voué à la migration.
Système maître et logiciel de paie : qui fait foi pour quoi
Lucca centralise les données administratives des collaborateurs, les absences, les temps et les notes de frais. Mais dans la majorité des cas, ce n’est pas Lucca qui calcule la paie ni qui transmet la DSN. Ce rôle revient au logiciel de paie existant.
Cette distinction crée un point de friction classique : quand un même champ existe dans Lucca et dans le logiciel de paie (un coefficient, une date d’ancienneté, un forfait jours), il faut désigner un système maître par champ. Faute de quoi, les corrections manuelles dans un outil écrasent celles de l’autre à la synchronisation suivante.
Cartographier les champs partagés
Nous recommandons de dresser un tableau des champs qui transitent entre Lucca et le logiciel de paie, en précisant pour chacun :
- Le système maître (celui où la saisie initiale et les corrections se font)
- Le sens du flux (Lucca vers paie, paie vers Lucca, ou bidirectionnel avec règle de priorité)
- La fréquence de synchronisation (événement, batch quotidien, batch mensuel avant clôture)
- Le traitement en cas de conflit (alerte, écrasement, file d’attente manuelle)
Toute variable de paie sans système maître désigné génère des écarts en clôture. Ce cadrage, réalisé au démarrage du projet, réduit considérablement les allers-retours entre l’équipe paie et l’équipe RH.
Droits d’accès API et conformité RGPD des flux RH
L’intégration technique ne se limite pas à faire passer des données d’un point A à un point B. Chaque flux entre Lucca et un autre outil constitue un traitement de données personnelles au sens du référentiel CNIL sur la gestion du personnel.
Concrètement, cela signifie que les droits d’accès API doivent être calibrés au strict nécessaire. Une clé API utilisée pour synchroniser les absences n’a pas besoin d’accéder aux données de rémunération. Le principe de minimisation s’applique aux permissions API, pas seulement aux interfaces utilisateur.
Points de vérification RGPD pour chaque connecteur
- Les données transitent-elles par un serveur intermédiaire (iPaaS, middleware) ? Si oui, ce tiers doit figurer dans le registre des sous-traitants
- Les logs de synchronisation conservent-ils des données personnelles ? Leur durée de rétention doit être définie
- Les collaborateurs sont-ils informés des flux automatisés entre Lucca et les autres systèmes, conformément à l’obligation de transparence
Ce volet est souvent traité après le go-live, alors qu’il devrait faire partie du cadrage initial. Un audit RGPD des flux d’intégration prend peu de temps quand il est mené en parallèle de la cartographie des champs.
Migration des données vers Lucca : les pièges de la reprise d’historique
Importer les données depuis un ancien SIRH ou depuis des fichiers Excel pose un problème que les guides génériques sous-estiment : la qualité des données source conditionne toute la suite. Un champ « date d’entrée » renseigné dans trois formats différents, des doublons de collaborateurs créés par des fusions de sociétés, des soldes de congés calculés manuellement avec des règles implicites – chaque anomalie migre avec le reste.
La reprise d’historique doit être traitée comme un projet de nettoyage de données, pas comme un simple import. Identifier les champs critiques (ceux qui alimentent la paie ou les compteurs d’absence), les nettoyer avant import, puis valider par échantillonnage après chargement dans Lucca.
Un point souvent négligé : les données de l’ancien système qui n’ont pas d’équivalent dans Lucca. Plutôt que de forcer un mapping approximatif, mieux vaut archiver ces données séparément et documenter leur localisation pour les équipes RH.
L’intégration de Lucca dans un environnement RH existant est avant tout un travail de plomberie documentée. Les modules s’activent vite. Ce qui prend du temps, c’est de garantir que chaque donnée arrive au bon endroit, dans le bon format, avec le bon niveau d’autorisation, et que quelqu’un sait où regarder quand un flux tombe en erreur.
