EWA pour les entreprises industrielles à plusieurs équipes : comment bien calculer les heures travaillées ?

Pour déployer l'EWA (accès au salaire gagné) dans une entreprise industrielle à plusieurs équipes, le système doit distinguer le planning d'équipe du travail réel ; les heures normales des heures supplémentaires ; les données en attente des données validées ; et les transactions intra-période des corrections post-clôture. Chaque enregistrement doit être rattaché au code employé, au jour de travail, à l'équipe, à l'usine, au statut d'approbation, au moment de mise à jour et à la version. L'entreprise devrait piloter dans une usine dont les données sont relativement stables, mesurer le taux de validation des heures dans les délais, la fraîcheur du plafond, le taux de transactions réussies et les écarts de paie avant de s'étendre.

> Remarque : Cet article est un cadre métier et technique de référence. La formule de rémunération, les éléments inclus dans le plafond, les limites, les processus d'approbation et le moment de liquidation doivent être confirmés par l'entreprise, le fournisseur EWA, la paie, les services juridiques et la comptabilité sur la base des dossiers réels.

> Explication des termes : EWA (perception du salaire selon les jours travaillés) · payroll (calcul de la paie) · HRIS (système d'information des ressources humaines) · ERP (progiciel de gestion intégré) · cutoff (clôture de période) · pilot (déploiement pilote) · UAT (recette utilisateur) · KPI (indicateur de performance) · workflow (flux de travail) · wave (vague d'extension) · dashboard (tableau de suivi) · go-live (mise en exploitation officielle).

Pourquoi l'environnement d'usine est-il un enjeu EWA à part entière ?

Les entreprises industrielles comptent souvent une main-d'œuvre importante, organisée en plusieurs équipes, avec des heures supplémentaires liées aux commandes, et des données qui traversent plusieurs niveaux : pointeuse, chef d'équipe, superviseur, RH, paie, comptabilité et banque. Avoir une équipe planifiée ne signifie pas avoir effectué l'équipe complète. Un enregistrement de badgeage ne signifie pas qu'il a été reconnu. Des heures supplémentaires déclarées ne sont pas nécessairement des heures supplémentaires réalisées et validées.

Dans cet environnement, le plus grand défi n'est pas d'afficher le bouton « Recevoir mon salaire », mais de répondre avec précision :

• le salarié travaille-t-il réellement et relève-t-il du programme ;

• quelle équipe est terminée ;

• quelles heures sont éligibles au calcul ;

• quels revenus sont suffisamment certains ;

• quel montant doit être retenu conformément à la politique ;

• comment la transaction précédente a été transférée et liquidée.

Si l'une de ces réponses est fausse, le plafond peut être supérieur ou inférieur à la réalité, ce qui accroît les réclamations et le volume de corrections en fin de période.

1. Cartographie des données, de l'équipe à la transaction EWA

```mermaid
flowchart TD
A["Planning des équipes"] --> B["Pointage entrée/sortie"]
B --> C["Traitement des exceptions"]
C --> D["Validation des heures et des heures supplémentaires"]
D --> E["Calcul de la rémunération éligible"]
E --> F["Plafond EWA"]
F --> G["Transactions et paiement"]
G --> H["Paie, comptabilité et rapprochement"]
```

Chaque étape doit avoir une source de données de référence et un responsable. Il ne faut pas laisser la plateforme EWA interpréter seule un badgeage en salaire si le processus de pointage n'a pas confirmé.

2. Distinguer planning d'équipe, données de pointage et heures validées

(Concept clé : voir Qu'est-ce que les heures validées ?.)

Planning d'équipe

Le planning d'équipe indique quand le salarié est censé travailler. Il sert à détecter les retards, les départs anticipés, les absences, les changements d'équipe ou les chevauchements d'équipes, mais il ne prouve pas que la personne a travaillé.

Données de pointage entrée – sortie

Des données d'événements enregistrées par la machine. Elles peuvent manquer en raison d'un oubli de badgeage, d'une panne d'équipement, d'une coupure réseau, d'un badgeage sur la mauvaise machine ou d'un travail effectué hors de l'emplacement habituel.

Heures validées

C'est le résultat métier après application des règles et traitement des exceptions. Selon la politique, seul ce statut est éligible au moteur de calcul du plafond.

Pourquoi ne pas utiliser « heures provisoires » sans le préciser ?

Si l'entreprise souhaite afficher un plafond à partir de données provisoires, elle doit disposer d'un mécanisme de couverture du risque, d'un libellé de statut, d'un taux de retenue et d'une méthode de recalcul lorsque les données changent. Le salarié doit comprendre pour quelle raison le montant disponible peut varier. Il ne faut pas afficher un chiffre qui semble certain alors que la source est encore en attente de validation.

3. Jeu minimal de champs de données pour une usine à plusieurs équipes

Profil employé

Équipe et heures

Paie et transactions

• payperiodid ;

• code de l'élément de revenu éligible ;

• version de la formule ;

• moment de la clôture ;

• statut de la période de paie ;

• transaction_id ;

• idempotency_key ;

• montant demandé, frais et montant réellement transféré ;

• statut EWA et paiement ;

• payment_reference ;

• plafond avant/après transaction ;

• version des données utilisées pour le calcul.

4. À quel jour doit appartenir l'équipe de nuit ?

Une équipe qui commence avant minuit et se termine le lendemain est une source courante d'écarts. Le système de pointage peut rattacher les événements au jour calendaire, tandis que la paie rattache l'ensemble de l'équipe au jour de début ou au jour de travail métier.

L'entreprise doit trancher :

1. le work_date de l'équipe de nuit est-il le jour de début ou le jour de fin ;

2. comment les heures et l'indemnité de nuit sont-elles séparées ;

3. à quel jour appartiennent les heures supplémentaires après l'équipe ;

4. comment sont traités les jours de repos/fériés qui coupent une équipe ;

5. quel est le fuseau horaire de référence ;

6. la clôture divise-t-elle une équipe en deux périodes ;

7. les rappels et données arrivant après coup sont-ils recalculés.

Exemple illustratif

Une équipe commence à 22 h 00 le 10 et se termine à 06 h 00 le 11. Si le pointage utilise le 11 et la paie le 10, l'EWA peut calculer en moins ou en double si le shiftid et le workdate ne sont pas unifiés.

Il ne faut pas résoudre le problème en comparant seulement le total d'heures du mois, car l'EWA doit savoir, à chaque instant, quelle part des heures est déjà éligible.

5. Quand les heures supplémentaires sont-elles incluses dans le plafond ?

Les heures supplémentaires ont généralement plusieurs statuts :

1. planifiées ;

2. déclarées ou acceptées par le salarié selon la procédure ;

3. présence effective ;

4. confirmation par le superviseur ;

5. approbation RH/Paie ;

6. période de paie verrouillée.

L'entreprise doit déterminer quel statut est éligible à l'EWA. Les heures supplémentaires peuvent rendre le plafond plus attractif, mais elles sont aussi plus volatiles que les heures normales.

Trois options de politique de référence

Quelle que soit l'option, elle doit être approuvée par la paie, les RH, les services juridiques et la gestion des risques. Il ne faut pas laisser l'EWA considérer d'office tout overtime_minutes comme un montant certain.

6. Congés payés, congés sans solde et heures manquantes

Ces situations affectent le plafond de manières différentes :

• les congés payés peuvent être comptabilisés selon la politique après approbation ;

• un congé sans solde ne génère pas de rémunération correspondante ;

• le repos compensateur peut être lié aux données d'une autre période ;

• un pointage entrée/sortie manquant nécessite une exception ;

• les retards/départs anticipés ont des règles d'arrondi ;

• l'arrêt de travail ou la mutation disposent de mécanismes dédiés ;

• les déplacements/formations peuvent ne pas apparaître sur la pointeuse.

L'entreprise devrait établir une table des codes de statut plutôt que de laisser chaque usine interpréter à sa manière.

Les valeurs du tableau doivent être confirmées par l'entreprise ; il s'agit d'un exemple de structure.

7. Corrections tardives des heures et versionnement du plafond

En usine, les heures peuvent être corrigées après que le salarié a effectué une transaction. Le système doit savoir :

• quel enregistrement a changé ;

• les valeurs avant et après ;

• qui a corrigé et qui a validé ;

• quelle version a servi au calcul du plafond ;

• quelles transactions sont affectées ;

• quand l'écart est traité ;

• s'il faut suspendre la transaction suivante.

Ne pas supprimer l'ancien enregistrement

Il faut créer une version ou un événement de correction. En cas d'écrasement direct, l'entreprise ne peut plus reconstituer pourquoi le plafond avait cette valeur au moment de la transaction.

Exemple de champs de traçabilité

```json
{
"employee_id": "EMP-000123",
"work_date": "2026-08-18",
"shift_id": "NIGHT-A",
"approvalstatus": "ADJUSTEDAPPROVED",
"regular_minutes": 480,
"overtime_minutes": 60,
"record_version": 4,
"sourceupdatedat": "2026-08-20T03:20:15Z"
}
```

Ce sont des données fictives pour l'illustration, et non une spécification officielle de Lương Ngày.

8. La validation des heures dans les délais, KPI pilote

Un projet peut avoir une bonne application mais échouer à cause de validations tardives. Si le salarié ne voit pas de plafond, il conclura que l'EWA ne fonctionne pas.

KPI recommandé

$$
\text{Taux de validation des heures dans les délais} = \frac{\text{Enregistrements à valider validés avant l'échéance}}{\text{Total des enregistrements à valider}} \times 100\%
$$

Il convient de suivre par :

• usine ;

• atelier ;

• équipe ;

• chef d'équipe/superviseur ;

• type d'exception ;

• jour dans la période ;

• délai entre la fin d'équipe et la validation.

L'objectif n'est pas de transformer le KPI en outil de sanction des superviseurs. Le tableau de bord doit indiquer les causes : panne d'équipement, liste d'employés erronée, trop d'exceptions, droits d'approbation manquants ou processus inadapté.

9. Comment calculer le plafond pour éviter des variations incompréhensibles ?

Une formule conceptuelle peut s'exprimer ainsi :

$$
\text{Plafond disponible} = \text{Rémunération éligible approuvée} \times \text{Taux autorisé} - \text{Montant retenu} - \text{Déjà perçu dans la période}
$$

Les composantes doivent être définies :

• quels revenus sont éligibles ;

• à quel statut se trouvent les heures ;

• le taux autorisé selon qui/quel groupe ;

• l'objectif du montant retenu ;

• une transaction en cours occupe-t-elle le plafond ;

• comment une correction des heures modifie le plafond ;

• quand le plafond est verrouillé pour la période de paie.

Il ne faut pas publier la formule détaillée ou les seuils de risque sans approbation. Le salarié doit recevoir une explication suffisante pour comprendre le montant affiché, sans nécessairement connaître la logique interne anti-fraude.

10. Intégration avec le système de pointage et la paie

(Exigences de données et architecture : voir Intégration de l'EWA avec le pointage, la paie et l'ERP.)

API quasi temps réel

Adaptée lorsque l'usine dispose d'un système moderne et nécessite une mise à jour rapide après validation. Il faut maîtriser l'authentification, les versions, les relances, l'arrivée de données désordonnées et la supervision des erreurs.

Fichier batch/SFTP

Adapté aux systèmes anciens ou aux processus de clôture planifiés. Le fichier nécessite un code de lot, un total d'enregistrements, une somme de contrôle, une version, des règles de nommage, une protection contre les doublons et un rapport d'erreurs ligne par ligne.

Synchronisation manuelle contrôlée

Utilisable dans un petit pilote. Il faut un modèle standard, un responsable de création/validation, des journaux, une vérification des totaux, une zone de stockage sécurisée et un plan pour supprimer les opérations manuelles lors de l'extension.

Ne pas connecter directement tous les systèmes de point

Une entreprise multi-sites peut avoir plusieurs pointeuses ou logiciels. Une couche d'intégration normalisée permet à l'EWA de recevoir le même modèle de données, au lieu d'écrire une logique spécifique pour chaque appareil.

11. Rapprochement à quatre axes en environnement industriel

(Détails : voir Rapprochement des transactions EWA avec la paie et la comptabilité.)

Le rapprochement doit relier :

1. les heures et le plafond ;

2. les transactions EWA ;

3. les résultats de paiement ;

4. la paie/l'ERP.

Écarts fréquents à rechercher

• heures corrigées mais plafond non mis à jour ;

• transaction réussie mais absente de la paie ;

• paiement réussi mais EWA en cours de traitement ;

• transaction saisie dans la mauvaise période ;

• une même transaction apparaissant deux fois ;

• un salarié parti ayant encore des transactions ;

• un remboursement non rétabli selon la procédure ;

• code employé correct mais mauvaise entité juridique/usine ;

• totaux conformes mais transactions individuelles en sur/sous-compensation.

Chaque écart nécessite un dossier, un responsable, un délai interne, des preuves et un approbateur de clôture.

12. Organisation du support aux salariés en usine

Les salariés en équipe peuvent rencontrer des problèmes en dehors des heures ouvrables. Les canaux de support doivent correspondre aux horaires d'utilisation réels.

Trois niveaux de support

Éléments requis du ticket

• code employé maîtrisé ;

• usine et équipe ;

• type de problème ;

• code de transaction le cas échéant ;

• moment ;

• statut des heures/du plafond ;

• actions effectuées ;

• interlocuteur suivant ;

• délai et résultat.

Le personnel de support ne doit jamais demander au salarié son mot de passe ou son OTP.

13. La communication sur site doit être simple mais complète

Le message doit expliquer :

• ce qu'est l'EWA ;

• quelle partie de l'argent peut être reçue ;

• pourquoi le plafond change ;

• les frais éventuels ;

• comment les transactions sont liquidées ;

• que faire lorsque les heures ne sont pas validées ;

• que faire en cas de changement de numéro de téléphone/compte de réception ;

• le canal pour signaler une transaction anormale ;

• l'EWA ne remplace pas le contrôle du bulletin de paie.

Canaux de communication

• onboarding ;

• réunion de début d'équipe ;

• affiche avec QR code ;

• vidéo courte ;

• application/SMS ;

• chef d'équipe ou RH sur site ;

• documentation bilingue lorsque la main-d'œuvre en a besoin.

Il ne faut pas former uniquement les chefs d'équipe puis supposer que tous les salariés ont compris. Il faut mesurer le taux d'atteinte, l'activation et les questions récurrentes.

14. Sécurité et confidentialité sur le site de production

(Cadre complet : voir Sécurité des données et confidentialité lors du déploiement de l'EWA.)

Les risques courants incluent le partage de téléphone, le changement de SIM, le support au guichet, des écrans exposant les données d'autrui et des fichiers Excel transmis par des canaux inappropriés.

Les contrôles nécessaires :

• vérification à l'activation et lors des transactions sensibles ;

• interdiction du partage de compte ;

• masquage du numéro de compte et des montants lors de l'affichage en public ;

• ne pas photographier/envoyer les bulletins de paie dans les groupes de discussion ;

• séparation des droits par usine et par mission ;

• journalisation des actions de support ;

• procédure de changement d'appareil/numéro de téléphone ;

• données de test simulées ou masquées ;

• durée de conservation et suppression des fichiers intermédiaires ;

• canal de signalement de perte de compte.

La Loi sur la protection des données personnelles n° 91/2025/QH15 et le Décret n° 356/2025/NĐ-CP entrent en vigueur le 1/1/2026. L'entreprise doit examiner les rôles, finalités, périmètres de traitement et droits des salariés sur l'architecture réelle.

15. Comment concevoir le pilote EWA dans une usine ?

(Feuille de route standard : voir Plan pilote EWA 90 jours pour les entreprises.)

Choisir le périmètre

Il convient de choisir un atelier ou un groupe d'équipes présentant :

• un besoin confirmé ;

• des données relativement bonnes ;

• des superviseurs prêts à valider les heures ;

• un processus de paie représentatif ;

• un support sur place suffisant ;

• pas trop de différences avec le site d'extension suivant.

Passer au moins par les cycles de vie essentiels

Le pilote doit vérifier :

• l'activation ;

• les heures normales et supplémentaires ;

• l'équipe de nuit ;

• les corrections d'heures ;

• les transactions réussies/échouées/indéterminées ;

• le rapprochement quotidien ;

• une période de paie complète ;

• les réclamations et le traitement des exceptions.

KPI du pilote

• part des éligibles disposant de données valides ;

• taux de validation des heures dans les délais ;

• délai entre la validation des heures et la mise à jour du plafond ;

• taux d'activation ;

• taux de transactions réussies ;

• délai de réception de l'argent ;

• tickets pour 1 000 transactions ;

• taux de rapprochement automatisé ;

• écarts par cause ;

• transactions indéterminées ;

• taux de blocage à tort ;

• coût d'exploitation par utilisateur/transaction.

Les objectifs chiffrés doivent reposer sur la base de référence et les capacités de l'usine, sans être copiés d'un autre projet.

16. Checklist UAT pour les équipes de production

Équipes et heures

• [ ] Équipe de jour complète.

• [ ] Équipe de nuit sur deux jours.

• [ ] Changement d'équipe avant et après la clôture.

• [ ] Pointage d'entrée manquant ou pointage de sortie manquant.

• [ ] Retard, départ anticipé et règles d'arrondi.

• [ ] Congés payés et congés sans solde.

• [ ] Déplacement/formation sans passage à la pointeuse.

Heures supplémentaires

• [ ] HS planifiées mais non réalisées.

• [ ] HS réalisées mais en attente d'approbation.

• [ ] HS validées.

• [ ] HS corrigées après validation.

• [ ] HS sur jour de repos/férié selon la procédure de l'entreprise.

Employés

• [ ] Nouvel embauché avant sa date d'effet.

• [ ] Salarié en pause.

• [ ] Salarié parti en cours de période.

• [ ] Salarié transféré d'usine/entité juridique.

• [ ] Code employé en doublon ou mappage erroné.

Transactions

• [ ] Demande dans la limite du plafond.

• [ ] Demande dépassant le plafond.

• [ ] Envoi en double avec la même clé anti-doublon.

• [ ] Timeout et résultat indéterminé.

• [ ] Échec du paiement.

• [ ] Transaction de remboursement.

Paie et rapprochement

• [ ] Transaction saisie dans la bonne période.

• [ ] Fichier d'import en double bloqué.

• [ ] Correction tardive des heures générant une correction traçable.

• [ ] Concordance EWA – paiement – paie – ERP.

• [ ] Écart créant un dossier et clôturé avec approbation.

17. Étendre d'une usine à plusieurs usines

Il ne faut pas copier la configuration à l'identique si les usines diffèrent en termes d'équipes, d'équipements, de paie ou d'entité juridique.

Découpage par vagues

Regrouper les usines qui partagent :

• le même système de pointage ;

• le même jeu de codes d'équipe ;

• la même politique de paie ;

• la même entité juridique ;

• les mêmes capacités de support ;

• le même niveau de préparation à la validation des heures.

Portes avant chaque vague

• mappage des employés et des équipes vérifié ;

• règles d'heures/supplémentaires signées et approuvées ;

• UAT propre à l'usine réalisée ;

• superviseurs formés ;

• tableau de bord et rapprochement couvrant le nouveau périmètre ;

• droits d'accès ouverts aux bonnes unités ;

• erreurs de la vague précédente traitées ;

• rollback prêt.

Suivre les KPI par usine pour détecter une baisse de performance lors de l'extension.

18. Erreurs courantes

Utiliser le planning d'équipe comme travail réel

Générer un plafond avant d'avoir la preuve du travail.

Considérer tout badgeage comme des heures valides

Ignorer les pointages manquants, les chevauchements d'équipes, les badgeages d'autrui et les exceptions.

Calculer la totalité des heures supplémentaires non validées

Accroître la volatilité du plafond et les corrections de fin de période.

Ne pas unifier la date de l'équipe de nuit

Provoquer des heures manquantes/doublées et une mauvaise période d'attribution.

Mesurer uniquement les transactions, pas la validation des heures

Ne pas voir le goulot d'étranglement chez les superviseurs.

Laisser les RH traiter tous les tickets

Les RH ne peuvent pas résoudre seules les erreurs de paiement, d'API, de rapprochement ou de fraude.

Étendre un pilote géré manuellement

Le résultat est flatteur mais ne reflète pas la capacité d'exploitation à l'échelle.

Écraser les corrections tardives des heures

Perdre la capacité de reconstituer le plafond au moment de la transaction.

Conclusion

L'EWA présente un potentiel particulier dans les entreprises industrielles à plusieurs équipes, mais la valeur n'apparaît que lorsque les heures sont confirmées avec exactitude et en temps utile. La plateforme doit distinguer planning d'équipe – pointage – heures validées, traiter clairement l'équipe de nuit et les heures supplémentaires, gérer le versionnement des données et rapprocher jusqu'à chaque transaction.

L'entreprise devrait commencer dans une usine aux données relativement stables, considérer le taux de validation des heures dans les délais comme KPI pilote et ne s'étendre par vagues qu'après avoir traversé une période de paie complète. Découvrez Lương Ngày pour les entreprises pour échanger sur l'audit des données de pointage et le périmètre du pilote Lương Ngày en usine.

Sources de référence

• Code du travail n° 45/2019/QH14

• Loi sur la protection des données personnelles n° 91/2025/QH15

• Décret n° 356/2025/NĐ-CP portant application de la Loi sur la protection des données personnelles

---

Auteur : Nguyễn Tấn Lộc — Expert du département stratégie, Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt.

Conseil de la solution Lương Ngày pour les entreprises : Hotline 0937.022.655 · E-mail info@nhankiet.vn · Lương Ngày pour les entreprises