Une mauvaise recommandation musicale se règle avec Suivant. Une erreur de paie peut empêcher quelqu’un de payer son logement. Je refuse donc de mettre recommandation et dépôt bancaire dans la même colonne simplement parce que les deux utilisent un modèle.

Le cœur d’un moteur de paie doit rester déterministe. Il lit l’employé, la période, les heures, taux, avantages et retenues, applique des règles versionnées, produit un registre, puis un lot bancaire. Chaque montant doit pouvoir être recalculé avec les mêmes entrées et règles.

temps + dossier employé -> validations -> règles de paie versionnées
                        -> brut -> retenues -> net -> contrôle
                        -> approbation -> fichier bancaire + grand livre

Un modèle probabiliste peut intervenir autour : classer une pièce, retrouver la règle applicable, expliquer une variation ou signaler un cas inhabituel. Il ne remplace pas la formule finale.

Détecter une anomalie sans décider qu’elle est fausse

Je construirais une fonction de revue :

1. le moteur calcule normalement la paie;
2. un service dérive variation du net, heures, prime, compte bancaire et retenues;
3. règles et modèle attribuent des signaux, pas un verdict;
4. les cas au-dessus du seuil entrent dans une file protégée;
5. une personne voit montant, comparaison, source et raison;
6. elle confirme, corrige dans le système source ou documente l’exception;
7. le moteur recalcule avant le fichier bancaire.

Une hausse de 40 % peut être une prime légitime. Le modèle ne doit pas la « corriger » vers la moyenne. Une anomalie sert à prioriser la vérification. Les cas confirmés et rejetés alimentent l’évaluation, pas automatiquement l’entraînement sans gouvernance.

Le journal relie période, employé, versions des règles et du modèle, signaux, décision, approbateur et recalcul. L’accès est limité, les renseignements sont masqués dans les logs techniques et la rétention suit le besoin légal et opérationnel. Un fournisseur externe ne reçoit que les champs nécessaires et ses conditions de traitement sont vérifiées.

Au Québec, les règles de protection des renseignements personnels imposent des obligations lorsqu’une entreprise rend une décision fondée exclusivement sur un traitement automatisé. La personne doit être informée et peut, sur demande, obtenir les renseignements utilisés ainsi que les raisons et principaux facteurs; elle doit pouvoir présenter ses observations à un membre du personnel capable de réviser. La Commission d’accès à l’information explique ces exigences pour le secteur privé. Toute fonction assistée n’est pas automatiquement une décision exclusivement automatisée, et ce billet ne remplace pas un avis juridique.

Le principe donne tout de même un bon test d’architecture : peut-on montrer les entrées, la règle ou le signal, la version et la personne qui a confirmé? Le chemin de contestation mène-t-il à quelqu’un qui peut réellement recalculer et corriger?

La panne doit favoriser le paiement juste, pas le modèle. Si le service d’anomalie tombe, la paie suit les contrôles déterministes existants ou la fenêtre de traitement est suspendue selon le risque; elle n’attend pas dans une file invisible. Si le moteur principal échoue, un runbook restaure données et version, réconcilie les lots et empêche le double dépôt avec un identifiant unique.

Je testerais dossiers normaux, prime rare, rétroactivité, changement bancaire, absence, données manquantes et correction après dépôt. On mesure faux signaux, anomalies manquées, délai de revue et erreurs monétaires, avec un poids énorme pour la dernière catégorie.

Le temps gagné vient après ces contrôles. Dans la paie, je place le modèle comme une lampe dirigée vers les dossiers à revoir : source visible, recommandation corrigeable et confirmation autorisée. Le montant bancaire reste la sortie d’un calcul reproductible et d’une responsabilité humaine claire.