Ensemble de 60 scénarios UAT pour l'accès au salaire déjà gagné avant le go-live

Ensemble de 60 scénarios UAT pour l'accès au salaire déjà gagné avant le go-live : du pointage au rapprochement de la paie

L'UAT de l'accès au salaire déjà gagné ne peut pas se limiter à vérifier "cliquer pour retirer et voir l'argent arriver". Un système peut bien fonctionner dans le flux standard mais échouer lorsque les heures sont modifiées, deux demandes arrivent en même temps, la banque est en timeout, un employé quitte l'entreprise ou la paie est clôturée. L'ensemble de 60 scénarios ci-dessous aide les entreprises à tester toute la chaîne avec des données et des résultats vérifiables.

> En bref : Ne passez en production que lorsque les tests prouvent que la bonne personne – les bonnes heures – le bon montant – le bon compte – pas de double paiement – rapprochement possible – dans la bonne période de paie. Toute erreur liée à l'argent, aux droits ou aux données personnelles doit avoir des critères de blocage clairs.

> Avertissement : Il s'agit d'une bibliothèque de scénarios de référence, qui ne remplace pas le plan de test du système. Ne testez pas des transactions destructrices ou des données réelles sans autorisation. Les montants, comptes et environnements de test doivent être approuvés par les parties concernées.

1. En quoi l'UAT diffère-t-il d'une démo ?

(Voir aussi : Ce que les entreprises doivent préparer pour déployer l'accès au salaire déjà gagné et Architecture d'intégration de l'accès au salaire déjà gagné.)

Une démo montre que le produit peut fonctionner dans une situation préparée. L'UAT répond à la question de savoir si le produit répond aux exigences métier signées dans des conditions réelles et exceptionnelles.

Chaque cas de test doit inclure :

• un code et un objectif ;
• des conditions préalables ;
• des données d'entrée ;
• des étapes d'exécution ;
• des résultats attendus ;
• des résultats réels ;
• des preuves ;
• l'exécutant/l'approbateur ;
• le niveau de gravité ;
• l'état et la date de retest.

2. Préparation des données UAT

Créer un ensemble d'utilisateurs simulés sous contrôle :

• nouveaux, en activité, ayant quitté l'entreprise et transférés ;
• personnes avec le même nom mais des identifiants différents ;
• travaillant pour un ou plusieurs clients ;
• heures normales, de nuit, manquantes, supplémentaires ;
• comptes corrects, incorrects, inexistants ;
• proches des seuils de limite ;
• transactions réussies, échouées, en attente et annulées ;
• périodes ouvertes, proches de la clôture et verrouillées.

N'utilisez pas d'identifiants ou de comptes réels en dehors du cadre approuvé.

3. Échelle de gravité des erreurs et conditions de blocage

Niveau	Exemple	Décision
P1 Critique	Double paiement, mauvaise personne, fuite de clés/données importantes	Bloquer le go-live
P2 Élevé	Montant incorrect, erreur de paie, dépassement de droits	Bloquer jusqu'à correction et retest
P3 Moyen	Notification incorrecte, flux exceptionnel difficile à utiliser	Évaluer le risque et plan de correction
P4 Faible	Erreur de présentation sans impact métier	Peut être mis en backlog si approuvé

Les critères finaux doivent être documentés dans le plan de test, pas de décisions émotionnelles le jour du go-live.

4. Groupe A — Dossiers et conditions d'utilisation (UAT 01–06)

UAT 01 — Personne active avec dossier complet

Attendu : connexion et affichage correct du client/fonctionnalité activée.

UAT 02 — Personne ayant quitté l'entreprise

Attendu : droits verrouillés selon la clôture ; pas de nouvelle demande possible.

UAT 03 — Personnes avec le même nom

Attendu : le système distingue par clé d'identification, pas de mélange d'heures/transactions.

UAT 04 — Identifiant manquant ou OCR non concordant

Attendu : pas de transaction possible ; affichage des instructions de résolution, pas de fuite de données d'autres personnes.

UAT 05 — Personne transférée à un autre client

Attendu : effet avant/après transfert correct ; pas de consultation erronée des données du client.

UAT 06 — Une personne travaillant à plusieurs endroits

Attendu : heures et montants disponibles correctement séparés pour chaque lieu ; total non doublé.

5. Groupe B — Pointage et synchronisation (07–14)

UAT 07 — Pointage en temps réel via application

Attendu : enregistrement apparaissant selon SLA, état initial correct.

UAT 08 — Synchronisation Google Sheet valide

Attendu : correspondance correcte personne/jour/plage ; rapport du nombre de lignes réussies.

UAT 09 — Ligne Sheet avec mauvais code utilisateur

Attendu : ajout à la liste d'erreurs, pas d'attribution erronée à une autre personne.

UAT 10 — Réimportation du même fichier/enregistrement

Attendu : pas de double comptabilisation des heures.

UAT 11 — Plage de nuit passant minuit

Attendu : attribution correcte de la plage/jour selon les règles du client.

UAT 12 — Formats d'heure/jour différents

Attendu : formats pris en charge correctement lus ; formats non pris en charge signalés clairement.

UAT 13 — Deux sources avec des données différentes

Attendu : application correcte de la source de vérité/règle de priorité et alerte émise.

UAT 14 — Job de synchronisation interrompu puis repris

Attendu : pas de perte/doublement d'enregistrements ; checkpoint et alerte corrects.

6. Groupe C — Approbation et modification des heures (15–20)

UAT 15 — Approbation par un superviseur valide

Attendu : changement d'état, enregistrement de l'approbateur/heure.

UAT 16 — Approbation par un client valide

Attendu : impact uniquement sur les personnes du périmètre client.

UAT 17 — Personne sans droit d'approbation

Attendu : refus au niveau du serveur et enregistrement dans le log.

UAT 18 — Deux approbations presque simultanées

Attendu : un résultat cohérent, pas de création d'événements en double.

UAT 19 — Modification des heures déjà approuvées

Attendu : retour à l'attente d'approbation, enregistrement avant/après et mise à jour du montant disponible selon les règles.

UAT 20 — Heures d'aujourd'hui/d'avenir

Attendu : non comptabilisées si les règles de jour clôturé ne sont pas respectées.

7. Groupe D — Formules et montants disponibles (21–28)

UAT 21 — Formule de base

Attendu : heures approuvées × tarif unitaire moins montant déjà reçu et réserve conforme au calcul manuel.

UAT 22 — Aucune heure approuvée

Attendu : montant disponible égal à 0 avec une raison compréhensible.

UAT 23 — Arrondi à 1 000 unités

Attendu : correct aux valeurs limites, pas d'arrondi supérieur.

UAT 24 — Montant partiellement reçu dans la période

Attendu : montant restant correctement réduit, pas de double déduction.

UAT 25 — Réserve selon le nombre de jours

Attendu : maintien des N derniers jours selon la configuration en vigueur.

UAT 26 — Réserve selon le taux/seuil

Attendu : application correcte des conditions ; interface expliquant la partie réservée.

UAT 27 — Changement de tarif en cours de période

Attendu : chaque heure utilise la bonne version de la politique ou règle approuvée.

UAT 28 — Plusieurs clients, plusieurs tarifs

Attendu : calcul séparé pour chaque lieu, pas de confusion de tarif.

8. Groupe E — Limites et contrôle d'utilisation (29–34)

UAT 29 — En dessous du minimum

Attendu : le système refuse avant l'émission de l'ordre.

UAT 30 — Exactement au minimum

Attendu : accepté si les autres conditions sont remplies.

UAT 31 — Exactement au plafond par ordre

Attendu : accepté ; dépassement d'une unité refusé/ajusté selon le design.

UAT 32 — Dépassement du plafond quotidien par plusieurs ordres

Attendu : total des ordres du jour ne dépassant pas la politique.

UAT 33 — Deux demandes simultanées avec le même montant disponible

Attendu : verrouillage empêchant le dépassement ou le double paiement.

UAT 34 — Changement de limite effectif

Attendu : bonne personne approuvant, bonne date d'effet et trace d'audit.

9. Groupe F — Comptes, appareils et identification (35–40)

UAT 35 — Compte VPBank au bon nom

Attendu : authentification réussie et affichage masqué approprié.

UAT 36 — Compte au mauvais nom

Attendu : utilisation interdite, instructions de résolution fournies.

UAT 37 — Compte inexistant/inaccessible

Attendu : état non vérifié maintenu, pas de paiement possible.

UAT 38 — Tentative de changement de compte verrouillé

Attendu : l'utilisateur ne peut pas changer en dehors du processus ; toutes les exceptions doivent être approuvées/enregistrées.

UAT 39 — Connexion sur un deuxième appareil

Attendu : application correcte de la politique un utilisateur-un appareil et processus de changement d'appareil.

UAT 40 — Session expirée/usurpée

Attendu : demande de ré-authentification ; ancien jeton ne permettant pas de transaction.

10. Groupe G — Transactions et banque (41–48)

UAT 41 — Transaction réussie

Attendu : un code d'ordre, montant/compte correct, état et reçu.

UAT 42 — Refus clair de la banque

Attendu : état d'échec correct ; montant disponible traité selon les règles.

UAT 43 — Timeout après envoi de l'ordre

Attendu : passage à l'attente, pas de nouveau paiement automatique avec un nouveau code.

UAT 44 — Réponse tardive après timeout

Attendu : mise à jour avec la même transaction, pas de double enregistrement d'argent.

UAT 45 — Envoi répété de l'ordre

Attendu : idempotence garantissant un résultat financier unique.

UAT 46 — Réponse avec signature/source incorrecte

Attendu : refus, alerte de sécurité ; pas de conversion en paiement effectué.

UAT 47 — Perte de connexion au service de paiement

Attendu : fail-closed, file d'attente/récupération selon le design, notification sans confusion.

UAT 48 — Interrupteur d'arrêt d'urgence

Attendu : blocage des nouveaux ordres ; transactions en attente sécurisées ; réactivation nécessitant autorisation et log.

11. Groupe H — Rapprochement et paie (49–55)

(Détails : voir Rapprochement des transactions de l'accès au salaire déjà gagné avec la paie et la comptabilité.)

UAT 49 — Relevé parfaitement concordant

Attendu : toutes les transactions correctement appariées et marquées comme rapprochées.

UAT 50 — Présent dans le système, absent du relevé

Attendu : exception générée, pas de conclusion ou correction sans preuve.

UAT 51 — Présent sur le relevé, absent du système

Attendu : détection du côté bancaire vers le système et transfert à l'enquête.

UAT 52 — Montant incorrect/code en double

Attendu : pas de couplage forcé ; alerte et verrouillage si nécessaire.

UAT 53 — Intégration des transactions dans la paie

Attendu : uniquement les transactions réussies, correctes pour personne/client/période.

UAT 54 — Transactions proches de la clôture

Attendu : application correcte des règles de période et explication possible du rapport de pont.

UAT 55 — Jours de travail déjà couverts

Attendu : pas de cumul dans la période suivante ; bulletin de paie et total des transactions concordants.

12. Groupe I — Gestion des droits, données et opérations (56–60)

UAT 56 — Consultation croisée des données par le client

Attendu : pas d'accès aux personnes/heures d'autres clients, même en modifiant l'URL/API.

UAT 57 — Droits superadmin sensibles

Attendu : actions de configuration/exception avec authentification, log et approbation selon les règles.

UAT 58 — Exportation de rapports et masquage des données

Attendu : bon périmètre ; identifiants/comptes masqués ; fichiers exportés contrôlés.

UAT 59 — Réclamation "débit mais non reçu"

Attendu : CSKH accède au bon code, voit toutes les preuves, pas de demande d'envoi de données par des canaux non sécurisés.

UAT 60 — Récupération après incident

Attendu : service récupéré selon l'objectif ; pas de perte/double paiement de transaction ; rapprochement confirmant l'état final.

13. Tests limites pour la configuration par défaut de l'accès au salaire déjà gagné

Si le client pilote utilise les valeurs par défaut dans le code, il faut au moins tester :

Paramètre	En dessous de la limite	À la limite	Au-dessus de la limite
Minimum/par transaction	49 000	50 000	51 000
Plafond/transaction	2 999 000	3 000 000	3 001 000
Plafond/jour	4 999 000	5 000 000	5 001 000
Arrondi	99 999	100 000	100 001

Les chiffres ci-dessus sont des valeurs techniques par défaut, pas un engagement pour tous les clients. Le plan de test doit utiliser la configuration réelle dans l'environnement pilote.

14. Matrice de preuves UAT

Groupe	Preuves minimales
Dossiers	Données sources, écran de résultat, log de synchronisation
Heures	Enregistrement avant/après, approbateur, trace d'audit
Formules	Tableur indépendant et résultat système
Comptes	Résultat de vérification avec données masquées
Transactions	Code d'ordre, chronologie d'état, log valide
Banque	Réponse et relevé de test
Paie	Fichier d'entrée, rapport de pont, modèle de bulletin de paie
Droits	Matrice de droits et tentative d'accès bloquée
Incidents	Chronologie, alerte, runbook et résultat de récupération

Des captures d'écran individuelles ne suffisent pas à prouver le flux de bout en bout.

15. Conditions suggérées pour le go-live

(Après le go-live : voir Opérations de l'accès au salaire déjà gagné après le go-live.)

• 100 % des scénarios P1/P2 exécutés et réussis ;
• plus d'erreurs pouvant entraîner un paiement incorrect, double ou un dépassement de droits ;
• heures, transactions, relevés et paie du pilote concordants ;
• toutes les erreurs P3 évaluées en termes de risque, avec un propriétaire et une échéance de correction ;
• configuration de production vérifiée indépendamment ;
• liste des personnes/clients pilotes exacte ;
• limites monétaires et interrupteur d'arrêt approuvés ;
• points de contact banque, RH, paie, sécurité et support client prêts ;
• surveillance/alertes opérationnelles ;
• plan de rollback et communication testés.

Ne pas imposer la condition "60/60" de manière rigide si certains tests ne s'appliquent pas ; il faut documenter la raison de l'exclusion et l'approbateur.

16. Processus de gestion des erreurs

1. Enregistrer l'erreur avec données et preuves de reproduction.
2. Classer selon l'impact réel.
3. Identifier le responsable du traitement, pas de renvoi entre parties.
4. Corriger dans un environnement contrôlé.
5. Refaire le test de l'erreur et les tests de régression associés.
6. Le responsable métier valide le résultat.
7. Mettre à jour la documentation, le runbook ou les contrôles si la cause n'est pas uniquement le code.

Ne pas fermer une erreur juste parce qu'elle "ne peut pas être reproduite" sans vérifier les logs, les données et les conditions temporelles.

17. Questions fréquentes

Qui doit signer le procès-verbal UAT ?

Il est recommandé d'avoir le responsable métier, le responsable produit/fournisseur et les représentants des domaines impactés tels que RH/paie, finance, IT ou sécurité selon RACI.

Faut-il transférer de l'argent réel lors de l'UAT ?

Privilégiez le sandbox ou les comptes/montants pilotes approuvés. Si un test en production est nécessaire, il doit être limité en portée, supervisé, immédiatement rapproché et avec un plan d'arrêt.

De nombreux tests unitaires peuvent-ils remplacer l'UAT ?

Non. Les tests unitaires vérifient les composants ; l'UAT prouve que le processus répond aux besoins des utilisateurs et aux politiques avec des données proches de la réalité.

Une petite erreur peut-elle bloquer le go-live ?

Cela dépend de l'impact. Une erreur de présentation peut ne pas bloquer ; une erreur qui fausse le montant, divulgue des données, affecte les droits ou le rapprochement doit être évaluée rigoureusement.

Faut-il refaire l'UAT après le go-live ?

Il est nécessaire de tester la régression lors de modifications de formules, limites, sources d'heures, banques, paie, droits, infrastructure ou de versions ayant un impact significatif.

---

Auteur : Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

Conseil en solutions d'accès au salaire déjà gagné pour les entreprises : Hotline 0937.022.655 · Email info@nhankiet.vn · Accès au salaire déjà gagné pour les entreprises