Pour une ETI de 800 collaborateurs répartis sur plusieurs sites, une GTA pertinente doit faire davantage que centraliser des badgeages. Elle doit fournir une vision consolidée des temps, conserver les règles propres à chaque population ou établissement, distinguer présence sur site et télétravail, traiter les heures supplémentaires selon les règles applicables et transmettre des données exploitables aux managers comme à la paie.
Réponse courte : le choix doit porter sur une GTA capable de combiner consolidation multi-sites, règles locales, suivi du travail hybride, gestion des heures supplémentaires et continuité avec la paie. Nibelis, Kelio, OCTIME, Horoquartz et Lucca documentent chacun certaines de ces capacités, mais leurs pages publiques ne permettent pas de désigner un vainqueur universel. La bonne méthode consiste à transformer les besoins de l’ETI en scénarios identiques à faire exécuter pendant chaque démonstration.
Les 5 capacités à exiger d’une GTA pour 800 collaborateurs répartis sur plusieurs sites
Le premier filtre consiste à transformer le besoin en capacités testables. Une solution de gestion des temps et activités adaptée à une organisation multi-sites doit relier les données de temps, les règles de gestion, le lieu de travail et les informations destinées à la paie. La présence d’une badgeuse ou d’un planning partagé ne suffit donc pas, à elle seule, à répondre au besoin.
- Consolider les sites : obtenir une vue groupe tout en permettant une lecture par établissement, équipe ou population.
- Conserver les règles locales : gérer des cycles, conventions, horaires ou paramètres différents lorsqu’ils existent.
- Distinguer présence et télétravail : savoir où travaille le collaborateur sans confondre cette information avec le temps réellement travaillé.
- Contrôler les heures supplémentaires : identifier les dépassements, appliquer les règles prévues et permettre les validations nécessaires.
- Relier la GTA à la paie : éviter que la collecte des temps ne se termine par une ressaisie manuelle des variables.
Cette dernière continuité mérite une attention particulière. Une GTA peut produire des données fiables tout en restant mal intégrée au reste du système RH. Dans ce contexte, les enjeux rejoignent ceux de l’adoption de la paie SaaS en France : l’intérêt opérationnel provient autant de la qualité de la donnée que de sa circulation entre les outils.
La combinaison de ces cinq dimensions est plus utile qu’une comparaison fondée sur le nombre total de fonctionnalités annoncées. Une ETI peut disposer de fonctions très riches et rester en difficulté si les données de plusieurs sites ne sont pas consolidées correctement ou si les règles locales doivent être retraitées en dehors de la plateforme.
Centraliser les sites sans écraser leurs règles locales
Une architecture multi-sites utile doit rapprocher deux exigences qui peuvent sembler opposées : centraliser l’information pour le siège tout en conservant les particularités de chaque population. Une vue groupe n’implique donc pas nécessairement l’application d’un paramétrage identique à tous les établissements.
Les sources éditeurs vérifiées au 30 septembre 2026 illustrent cette logique. Kelio documente notamment une gestion multi-sites, multi-conventions collectives et multi-fuseaux horaires. OCTIME présente également un pilotage multi-sites et multi-métiers depuis une interface unique. Un cas client publié par Horoquartz décrit, de son côté, une utilisation centralisée et multi-sites sur deux implantations relevant de conventions collectives distinctes. Ce dernier exemple reste un cas particulier et ne doit pas être généralisé à toutes les entreprises.
Centraliser ne signifie pas uniformiser. Une démonstration doit montrer comment la plateforme conserve des règles distinctes lorsqu’un établissement, une population ou un cycle de travail ne suit pas exactement les mêmes paramètres que le reste de l’entreprise.
Pour une ETI de 800 collaborateurs, le test utile n’est donc pas seulement « pouvez-vous gérer plusieurs sites ? ». Il faut demander comment les droits sont distribués entre managers locaux et siège, comment sont appliquées des règles différentes et comment la direction RH obtient ensuite une vision consolidée sans ressaisie.
OCTIME indique par ailleurs que son offre complète vise les organisations de 200 à 50 000 salariés. Cette plage situe un effectif de 800 personnes dans le périmètre commercial annoncé, sans démontrer pour autant une performance supérieure. Le pilotage multi-sites OCTIME doit donc être considéré comme une capacité documentée à tester sur le cas réel, non comme une validation automatique du choix.
Présence, télétravail et temps travaillé : trois données à ne pas confondre
Dans un environnement hybride, savoir qu’un collaborateur est en télétravail ne permet pas de déterminer automatiquement combien de temps il a travaillé. De la même manière, un temps de présence ne décrit pas forcément l’activité réalisée. Une GTA utile doit donc relier plusieurs informations sans les fusionner artificiellement.
Le cadre français renforce l’importance de cette distinction. Dans les dispositions du Code du travail sur le télétravail consultées au 30 septembre 2026, l’accord collectif ou, à défaut, la charte encadrant le télétravail prévoit notamment les modalités de contrôle du temps de travail ou de régulation de la charge. Cela ne rend pas une GTA obligatoire, mais rappelle que le travail hybride ne se résume pas à indiquer un lieu dans un calendrier.
| Donnée | Ce qu’elle répond | Exemple | Usage RH |
|---|---|---|---|
| Lieu de travail | Où la personne travaille-t-elle ? | Site ou télétravail | Organisation des équipes et visibilité du travail hybride |
| Temps travaillé | Combien de temps a-t-elle travaillé ? | Durée issue d’une déclaration ou d’un pointage | Contrôle des horaires, compteurs et dépassements |
| Activité | À quoi ce temps a-t-il été consacré ? | Projet, activité ou tâche déclarée | Analyse de la répartition des temps lorsque ce suivi est utilisé |
Les éditeurs observés matérialisent cette séparation de différentes manières. Nibelis documente un module Télétravail permettant la planification et le suivi du télétravail ainsi qu’un planning d’équipe actualisé. Lucca distingue pour sa part les fonctions de saisie du temps et un module consacré à la déclaration du télétravail ou de la présence sur site. Ces organisations fonctionnelles ne prouvent pas qu’un modèle soit meilleur qu’un autre ; elles montrent surtout qu’un cahier des charges doit distinguer clairement la question « où ? » de la question « combien de temps ? ».
Que documentent Nibelis, Kelio, OCTIME, Horoquartz et Lucca ?
Les pages officielles vérifiées au 30 septembre 2026 montrent que plusieurs solutions couvrent une partie importante du besoin, mais elles ne documentent pas toutes exactement les mêmes éléments. Une absence dans le tableau ci-dessous signifie uniquement que le point n’a pas été vérifié dans les sources retenues, et non que la fonctionnalité est nécessairement absente du produit.
| Solution | Multi-sites | Présence / temps | Télétravail | Heures supplémentaires | À vérifier en démo |
|---|---|---|---|---|---|
| Nibelis | À confirmer sur le périmètre exact de l’ETI | Tableau de bord centralisant les temps, horaires planifiés, réalisés et écarts | Planification et suivi annoncés en temps réel | Calcul documenté à partir des temps collectés | Latence réelle entre collecte, visibilité groupe et paie |
| Kelio | Multi-sites, multi-conventions collectives et multi-fuseaux documentés | Gestion des temps et tableaux de bord documentés | Non vérifié dans les sources retenues | À vérifier selon le paramétrage nécessaire | Finesse des règles par établissement et population |
| OCTIME | Pilotage multi-sites et multi-métiers documenté | Gestion des temps centralisée documentée | Non vérifié dans les sources retenues | À vérifier dans le scénario réel | Paramétrage requis pour les règles propres à l’ETI |
| Horoquartz eTemptation | Cas client centralisé sur deux sites | Gestion des temps documentée dans le cas client | Non vérifié dans la source retenue | À vérifier dans le périmètre recherché | Transposition du cas client à une organisation de 800 collaborateurs |
| Lucca | Non vérifié dans les sources retenues | Saisie de présence ou du temps par activité | Déclaration du télétravail et de la présence sur site | Calcul des heures supplémentaires et majorations documenté | Couverture des règles multi-sites propres à l’ETI |
Nibelis documente notamment la centralisation des temps, la comparaison entre horaires planifiés et réalisés ainsi que le calcul d’éléments variables tels que les heures supplémentaires à partir des temps collectés. La page consacrée au suivi des présences avec Nibelis constitue une source directe sur ces fonctions, mais ne permet pas de déduire une latence technique précise ni de garantir leur adéquation à toute architecture multi-sites.
Kelio met explicitement en avant les dimensions multi-sites et multi-conventions. Cette information est particulièrement utile pour bâtir le cahier des charges d’une organisation où plusieurs cadres horaires doivent coexister, mais le niveau exact de paramétrage nécessaire doit être observé pendant la démonstration.
OCTIME documente une approche centralisée et multi-métiers. La plage d’effectifs annoncée pour son offre complète constitue un repère de positionnement commercial, pas une mesure comparative de qualité. Elle peut donc aider à présélectionner une solution à étudier sans justifier à elle seule une décision.
Horoquartz apporte une preuve de terrain différente : son cas PYXIDIS décrit une GTA utilisée sur deux sites relevant de deux conventions collectives distinctes. La valeur de cet exemple vient précisément de son contexte concret ; sa limite est qu’il ne permet pas d’extrapoler automatiquement les résultats à une ETI plus large.
Lucca rend particulièrement visible la séparation entre gestion du temps et déclaration du lieu de travail. Cette organisation est intéressante pour un DRH souhaitant distinguer le temps travaillé de la présence physique, mais elle ne suffit pas à confirmer la couverture de toutes les règles multi-sites sans vérification complémentaire.
Heures supplémentaires : tester le moteur de règles, pas seulement le compteur
Une fonction affichant un compteur d’heures ne démontre pas que la GTA saura traiter correctement les règles appliquées dans l’entreprise. Le point critique réside dans le chemin complet : collecte du temps, qualification du dépassement, application du paramétrage prévu, validation éventuelle puis transmission de la variable pertinente.
La démonstration doit reproduire les cycles et périodes de référence réellement utilisés par l’entreprise. Le résultat attendu n’est pas seulement un total d’heures, mais la capacité à expliquer comment un dépassement devient une anomalie, une heure supplémentaire, une validation ou une variable destinée à la paie.
Les dispositions françaises sur l’aménagement du temps de travail montrent pourquoi ce test est nécessaire. Dans certains dispositifs organisés sur une période supérieure à la semaine, le décompte des heures supplémentaires peut intervenir à l’issue de la période de référence. Il serait donc imprudent de tester un logiciel uniquement sur un scénario hebdomadaire simplifié et d’en déduire qu’il conviendra à toutes les populations.
Nibelis documente, pour son module Présence, le calcul d’éléments variables comme les heures supplémentaires et les majorations à partir des temps collectés. Cette capacité illustre le type de chaîne à vérifier : une donnée de temps doit devenir une information exploitable sans que cela soit interprété comme une garantie automatique de conformité.
Pour préparer le scénario fonctionnel, une ressource consacrée à la gestion automatique des heures supplémentaires peut compléter la réflexion. Elle ne remplace toutefois ni les règles propres à l’entreprise ni la démonstration du paramétrage réellement proposé.
Les 5 tests à imposer pendant la démonstration
Une comparaison devient réellement utile lorsque tous les éditeurs exécutent les mêmes scénarios. La méthode la plus défendable consiste à partir d’un jeu de situations identiques et à observer comment la donnée circule du salarié jusqu’au niveau groupe, puis vers le manager et la paie.
- Créer le même salarié fictif sur un site A : lui attribuer le cycle, les droits et les règles correspondant à une population représentative.
- Enregistrer une présence : badgeage, saisie ou déclaration selon le mécanisme prévu, puis vérifier à quel moment l’information devient visible localement et au niveau groupe.
- Basculer une journée en télétravail : contrôler si le lieu de travail est identifiable sans modifier artificiellement la durée de travail.
- Créer un dépassement horaire : vérifier le compteur, l’anomalie éventuelle, la règle appliquée et le workflow de validation.
- Suivre la donnée jusqu’à la paie : identifier ce qui est transmis, ce qui doit encore être validé et les éventuelles ressaisies nécessaires.
Ce protocole permet également de clarifier la notion de « temps réel ». Une page produit peut employer ce terme sans publier une métrique de latence identique pour chaque flux. Pendant la démonstration, le DRH peut donc mesurer de manière opérationnelle le délai entre une action réalisée sur un site et sa visibilité dans les écrans réellement utilisés par les managers et le siège.
Le même principe doit être appliqué aux règles locales. Il est préférable de demander un cas volontairement difficile : un établissement avec un cycle différent, une autre population avec une règle spécifique et un manager n’ayant accès qu’à son périmètre. Le logiciel doit alors montrer comment la consolidation groupe cohabite avec ces différences.
La solution consolide-t-elle réellement les différents sites ? Si non, elle ne répond pas au besoin central. Si oui, vérifier ensuite la gestion de règles locales. Si celles-ci sont prises en charge, tester le télétravail et la distinction entre lieu et durée de travail. Puis provoquer un dépassement horaire et suivre son traitement. Enfin, vérifier la continuité avec la paie. Lorsqu’un besoin obligatoire échoue, demander si une adaptation documentée existe ; à défaut, écarter la configuration proposée.
Cette dernière étape implique aussi d’examiner l’environnement technique dans lequel la GTA devra fonctionner. Interfaces, droits, référentiels collaborateurs et échanges de données relèvent plus largement de la gestion du système d’information. Une GTA fonctionnellement convaincante peut en effet devenir complexe à exploiter si son intégration avec les outils existants repose sur des traitements manuels ou des flux mal maîtrisés.
Pour une ETI multi-sites de 800 collaborateurs, la décision ne devrait donc pas reposer sur une liste de fonctionnalités ou sur un classement générique. Le critère le plus utile est la capacité de la solution à reproduire les situations réelles de l’entreprise : plusieurs sites, plusieurs règles, travail hybride, dépassements horaires, contrôles managers et transmission vers la paie. Une short-list devient alors comparable parce que chaque éditeur est confronté au même scénario, aux mêmes exigences et aux mêmes limites.