Le fait générateur, dont l’application est prévue à compter du 1er janvier 2027, ne concerne pas uniquement les logiciels de paie. Les outils de gestion des temps et des activités (GTA) sont eux aussi directement concernés.
Pourquoi ? Parce qu’une grande partie des éléments variables de paie trouve son origine dans les données collectées par la GTA : heures supplémentaires, absences, astreintes, majorations, primes liées au temps de travail…
Avec le fait générateur, la logique évolue : les données devront être rattachées à la période et à l’événement auxquels elles correspondent, y compris lorsqu’elles sont corrigées ou transmises ultérieurement.
Pour les entreprises, l’enjeu est donc d’anticiper dès maintenant les évolutions nécessaires côté processus, paramétrage, historisation et interfaces GTA/paie.
Fait générateur : rappel du principe
Aujourd’hui, les éléments variables sont généralement intégrés dans la paie du mois au cours duquel ils sont traités. Une correction concernant une période antérieure peut ensuite être régularisée sur une paie ultérieure.
Le fait générateur introduit une logique différente : l’événement doit être rattaché à la période à laquelle il se rapporte réellement.
Prenons un exemple.
Une absence du mois d’avril est requalifiée en mai. L’information est donc connue en mai, mais elle concerne bien un événement intervenu en avril.
Avec la logique du fait générateur, cette information doit pouvoir être identifiée comme se rapportant à avril, même si sa saisie ou sa correction intervient plusieurs semaines plus tard.
Cette distinction entre date de l’événement, date de saisie ou de modification et date de transmission devient donc essentielle.
Et c’est précisément à ce niveau que la GTA entre en jeu.
Pourquoi la GTA est directement concernée ?
La GTA constitue l’un des principaux points d’entrée des données qui alimentent la paie.
Elle permet notamment de collecter et calculer :
- les temps de présence ;
- les absences et congés ;
- les heures supplémentaires ;
- les heures complémentaires ;
- les astreintes ;
- les majorations ;
- certaines primes liées au temps de travail ;
- les corrections de pointage.
Le processus peut être schématisé simplement :
Événement → GTA → contrôle et validation → interface → paie → DSN
Jusqu’à présent, une correction tardive pouvait souvent être traitée comme une simple rétroactivité dans la paie.
Demain, il faudra être capable de retrouver l’origine de la donnée, sa période de rattachement et son historique, puis de transmettre à la paie les informations nécessaires à la régularisation.
La GTA ne sera donc plus seulement un outil de collecte des temps. Elle deviendra un maillon essentiel de la fiabilisation du fait générateur.
Les 5 impacts à anticiper côté GTA
1. Revoir la gestion des corrections après clôture
C’est probablement l’un des premiers sujets à examiner.
Une période de GTA est généralement clôturée après validation des données par les managers. Mais que se passe-t-il lorsqu’une information arrive après cette clôture ?
Quelques exemples :
- un justificatif d’absence transmis tardivement ;
- une absence requalifiée ;
- une heure supplémentaire validée après la clôture ;
- une erreur de pointage détectée a posteriori ;
- une prime ou une majoration ajoutée après transmission à la paie.
Avec le fait générateur, ces situations devront être identifiées, tracées et correctement rattachées à leur période d’origine.
L’objectif n’est donc plus simplement de « rouvrir » une ancienne période ou de reporter la correction sur le mois suivant.
Il faut pouvoir déterminer précisément ce qui a changé et quel est son impact sur une donnée déjà transmise à la paie.
La bonne question à poser à son éditeur
Comment votre GTA gère-t-elle une modification effectuée après la clôture d’une période déjà transmise en paie ?
2. Renforcer l’historisation et la traçabilité
Le fait générateur rend la notion d’historique des données particulièrement importante.
Une GTA doit pouvoir permettre de reconstituer, autant que nécessaire :
- la valeur initiale d’une donnée ;
- la nouvelle valeur ;
- la date de l’événement ;
- la date de saisie ;
- la date de modification ;
- l’auteur de la modification ;
- la période de GTA concernée ;
- et, lorsque c’est pertinent, la transmission déjà effectuée vers la paie.
Cette capacité d’historisation est essentielle pour comprendre l’origine d’une régularisation et sécuriser les échanges entre les systèmes.
Une donnée corrigée ne doit pas faire disparaître la donnée d’origine.
La profondeur d’historisation proposée par la solution devient donc un véritable critère à prendre en compte lors d’un projet GTA ou SIRH.
3. Faire évoluer les processus de validation des temps
Le fait générateur renforce également l’importance de la qualité des données avant clôture.
Aujourd’hui déjà, les managers jouent un rôle essentiel dans la validation des temps et des absences. Demain, cette étape sera encore plus stratégique.
Une anomalie non détectée avant la clôture peut en effet générer une correction ultérieure, avec des conséquences sur une période de paie déjà traitée.
Il peut donc être nécessaire de revoir :
- les calendriers de validation ;
- les relances managers ;
- les contrôles avant clôture ;
- les règles de blocage ;
- les workflows de correction ;
- la gestion des anomalies après clôture.
L’objectif : traiter le maximum d’anomalies avant la transmission des données à la paie.
Certaines anomalies critiques pourront également justifier un blocage de la clôture tant qu’elles ne sont pas corrigées.
4. Repenser les interfaces GTA ↔ paie
C’est un autre chantier majeur.
Une interface GTA/paie ne devra plus uniquement transmettre les éléments variables du mois.
Elle devra également permettre d’identifier les données nouvelles ou corrigées ayant un impact sur une période antérieure.
Prenons un cas simple :
Une heure supplémentaire réalisée en avril n’est validée par le manager qu’en mai.
L’outil doit permettre de conserver l’information selon sa période d’origine et de transmettre à la paie les éléments nécessaires à son traitement.
La question n’est donc plus seulement :
« Quels EVP devons-nous transmettre ce mois-ci ? »
Mais aussi :
« Quels événements ont été modifiés depuis la dernière transmission et quelles périodes de paie sont concernées ? »
Cette évolution peut nécessiter une revue complète des interfaces existantes : structure des flux, règles de gestion, fréquence des échanges, gestion des corrections et traçabilité.
5. Clarifier les rôles et responsabilités
Le fait générateur n’est pas uniquement un sujet technique.
Il implique une responsabilisation accrue de l’ensemble des acteurs intervenant dans la chaîne GTA/paie.
intervenant dans la chaîne GTA/paie.
| Acteur | Enjeu |
|---|---|
| Collaborateur | Transmettre rapidement ses absences et justificatifs |
| Manager | Contrôler et valider les temps dans les délais |
| Gestionnaire GTA / RH | Traiter les anomalies et les corrections |
| Gestionnaire de paie | Identifier et traiter les impacts en paie |
| Équipe SIRH / IT | Sécuriser les flux et les interfaces |
| Éditeur | Faire évoluer la solution et son paramétrage |
La réussite du passage au fait générateur dépendra donc autant de la fiabilité de la solution GTA que de la capacité de l’entreprise
à adapter ses processus.
Votre GTA est-elle prête pour le fait générateur ? Les 7 questions à poser
Avant 2027, un premier diagnostic peut être réalisé directement avec votre éditeur ou intégrateur GTA.
1. Historisation
Notre solution conserve-t-elle l’historique complet des modifications ?
2. Dates
Peut-elle distinguer la date de l’événement de sa date de saisie ou de modification ?
3. Corrections
Comment sont gérées les modifications après clôture d’une période ?
4. Traçabilité
Pouvons-nous identifier qui a modifié une donnée, quand et pourquoi ?
5. Interface
Les échanges GTA/paie permettent-ils d’identifier les corrections portant sur des périodes antérieures ?
6. Contrôles
Quels contrôles et blocages peuvent être automatisés avant la clôture ?
7. Roadmap
Quelle est la roadmap de l’éditeur concernant l’adaptation au fait générateur ?
👉 Si plusieurs réponses restent floues, c’est probablement le bon moment pour lancer un audit de l’existant.
Comment anticiper le fait générateur côté GTA ?
Il n’est pas nécessaire d’attendre 2027 pour commencer.
Les entreprises peuvent dès maintenant structurer leur démarche autour de 4 chantiers.
1. Cartographier
Identifier les données GTA qui alimentent la paie :
absences → temps → compteurs → EVP → paie
Puis documenter les interfaces et les règles de gestion associées.
2. Auditer
Vérifier les capacités de la solution en matière :
- d’historisation ;
- de traçabilité ;
- de corrections post-clôture ;
- de gestion des périodes antérieures ;
- d’interfaces avec la paie.
3. Adapter
Faire évoluer si nécessaire :
- les workflows ;
- les calendriers de validation ;
- les contrôles ;
- les règles de clôture ;
- les processus de correction.
4. Tester
Ne pas se contenter de vérifier que l’outil « sait gérer » les corrections.
Il faut tester des cas réels :
- absence requalifiée ;
- heure supplémentaire validée tardivement ;
- correction de pointage ;
- modification après clôture ;
- élément variable transmis puis corrigé.
L’objectif est de vérifier toute la chaîne :
GTA → interface → paie → régularisation
2027 se prépare dès maintenant
Le fait générateur marque une évolution importante dans la manière dont les données RH sont rattachées et traitées.
Pour la GTA, l’enjeu dépasse donc largement une simple évolution de paramétrage.
Il s’agit de garantir que chaque événement soit correctement rattaché à sa période d’origine, que les corrections soient traçables et que les échanges avec la paie permettent de traiter les éventuelles régularisations.
Pour les entreprises, plusieurs chantiers doivent être anticipés : audit des processus GTA, revue des paramétrages, contrôle de l’historisation, analyse des interfaces GTA/paie et tests de scénarios de correction.
Plus qu’une mise à jour réglementaire, le fait générateur invite donc à repenser la chaîne de données entre la gestion des temps et la paie.
Votre GTA est-elle prête pour le fait générateur ?
Fortify vous accompagne dans l’audit de votre existant,
l’analyse de vos flux GTA/paie et l’identification des
adaptations à prévoir pour anticiper les évolutions liées au fait générateur.
FAQ – Fait générateur et GTA
Le fait générateur concerne-t-il les outils de GTA ?
Oui. Les données issues de la gestion des temps et des activités (GTA)
alimentent directement la paie. Les heures supplémentaires, absences, astreintes,
majorations ou autres éléments variables doivent donc pouvoir être rattachés à leur
période d’origine et être correctement tracés en cas de correction.
Pourquoi l’historisation des données GTA est-elle importante avec le fait générateur ?
L’historisation permet de retrouver l’origine d’une donnée GTA,
les modifications effectuées, leur date et la période concernée. Elle devient
particulièrement importante lorsqu’une correction intervient après la clôture
d’une période ou après la transmission des données à la paie.
Comment gérer une correction GTA après la clôture d’une période ?
Une correction effectuée après clôture doit pouvoir être identifiée,
tracée et rattachée à la période d’origine. La GTA doit notamment permettre
de distinguer la date de l’événement de la date de saisie ou de modification afin
que l’impact éventuel sur la paie puisse être correctement traité.
Quel est l’impact du fait générateur sur les interfaces GTA et paie ?
Les interfaces GTA/paie doivent pouvoir gérer non seulement les éléments variables
du mois, mais également les événements corrigés ou ajoutés concernant une
période antérieure. Il est donc nécessaire de vérifier les règles de
transmission, la gestion des corrections et la traçabilité des données échangées.
Faut-il changer de logiciel GTA pour se conformer au fait générateur ?
Pas nécessairement. Avant d’envisager un changement de solution, il est recommandé
de réaliser un audit de l’outil GTA existant : historisation,
gestion des corrections après clôture, workflows de validation, paramétrage et
interfaces avec la paie. Cet audit permet d’identifier les éventuels écarts et
les adaptations nécessaires.
Quand faut-il préparer sa GTA au fait générateur ?
Il est recommandé d’anticiper dès maintenant les évolutions liées au fait générateur.
La démarche peut commencer par une cartographie des flux GTA/paie,
suivie d’un audit des processus, du paramétrage et des capacités d’historisation,
puis par des tests sur différents scénarios de correction et de régularisation.
