Rapport d’assurance final : Audit de la validation de la paye : Migration de la base de données de Phénix

Audit interne Bureau du dirigeant principal d’audit, d’évaluation et de gestion du risque

Sur cette page

• 1. Sommaire
• 2. Réponse de la direction
• 3. Contexte
• 4. Focalisation de la mission d’assurance
  • 4.1 Objectif
  • 4.2 Portée
  • 4.3 Secteur d’intérêt, critères et méthodologie
• 5. Observations détaillées et leçons apprises
  • 5.1 Rôles, responsabilités, obligations de rendre compte et pouvoirs
  • 5.2 Processus relatif aux points de contrôle
  • 5.3 Résultats des tests de validation de la paye
  • 5.4 Critères de réussite pour la validation de la paye
• 6. Conclusion
• 7. Remerciements
• Annexes:
  • Annexe A : Sigles et abréviations
  • Annexe B : Lexique
  • Annexe C : Secteur d’intérêt, critères et méthodologie
  • Annexe D : Cycles de validation de la paye et leur objectif
  • Annexe E : Critères de réussite pour la validation de la paye qui ont été approuvés

1. Sommaire

À titre d’administrateur de la paye et des pensions, Services publics et Approvisionnement Canada (SPAC) administre la paye de plus de 400 000 employés dans plus de 100 ministères, organismes et sociétés d’État qui utilisent le système de paye Phénix. Le Ministère fournit également des services-conseils complets en rémunération et du soutien direct à la clientèle à quelque 270 000 de ces employés; il fournit également un soutien et un leadership techniques de bout en bout pour toutes les applications liées à la paye.

Le fournisseur du système de paye Phénix cessera d’offrir du soutien pour la base de données et la plateforme de développement en avril 2025. À ce moment-là, SPAC sera exposé à des risques élevés de vulnérabilités en matière de sécurité et de dégradation des services, ce qui pourrait avoir une incidence sur la capacité de SPAC à verser une paye exacte et en temps opportun à ses employés, ainsi qu’au risque associé au vieillissement des systèmes de technologie de l’information. Pour atténuer ces risques opérationnels, SPAC a lancé le projet de migration de la base de données du système de paye et de PeopleTools (ci-après le « projet ») sous la direction de la Direction générale des solutions du portefeuille de Gestion du capital humain. Ce projet, qui a commencé en avril 2022 et devait s’étendre sur 2,5 ans, consiste à migrer le système de paye de la base de données DB2 d’International Business Machines Corporation (IBM) vers une nouvelle base de données Oracle de même qu’à mettre à niveau la plateforme de développement PeopleTools. Le projet comprend la gouvernance, la mobilisation des parties prenantes et les tests. Les tests de validation de la paye sont un élément du processus de test global qui vise à confirmer qu’après la migration, le système de paye produira des résultats semblables. La migration de la base de données de Phénix vers la base de données Oracle a eu lieu le 22 octobre 2024, et il n’est pas possible de revenir à la base de données DB2. 

L’objectif de cette mission d’assurance était d’évaluer, avant la migration, l’efficacité du processus des tests de validation de la paye, ainsi que les résultats du rapprochement des traitements de paye exécutés à partir de la base de données actuelle et de la nouvelle base de données.

En ce qui concerne le processus des tests de validation de la paye, les rôles, les responsabilités, les obligations de rendre compte et les pouvoirs ont été largement définis, documentés, communiqués et compris. Cela dit, bien que les rôles et les responsabilités de la ou des personnes qui prennent la décision de passer chaque point de contrôle du cycle de test de validation de la paye, ainsi que les procédures d’acheminement aux échelons supérieurs de l’entreprise ou à la gouvernance n’aient pas été entièrement documentés, ils ont été communiqués et compris par l’équipe de projet.

De plus, le processus relatif aux points de contrôle s’est déroulé comme prévu, et consistait notamment à fournir les approbations en temps opportun, qui avaient été pour l’essentiel documentées. Les résultats des tests de validation de paye pour les dix points de contrôle du cycle V5, ont été évalués et rapprochés des résultats de l’équipe de projet en termes d’écarts de valeur en dollars. Il a en outre été établi que les résultats de l’équipe de projet dans les rapports de synthèse pour chaque point de contrôle étaient conformes au plan de test de la mise à niveau de cette équipe. Enfin, l’audit interne a permis de constater que ce cycle répondait aux critères de réussite.

Un problème ayant été repéré dans le cycle V5, l’équipe de projet a créé un nouvel environnement, le cycle V5B, en tant qu’instance de validation, dans lequel un changement de codage a été appliqué. Bien que ce cycle ait été la solution recommandée par l’équipe de projet aux fins de la transition vers la production, elle a choisi de ne pas produire les fichiers justificatifs détaillés requis par l’équipe d’audit interne en raison de contraintes de budget et de calendrier. Ainsi, l’équipe d’audit interne n’a pu donner l’assurance que le cycle V5B répondait aux critères de réussite.

En outre, l’équipe de projet a pu utiliser les mêmes critères de réussite pour la validation de la paye qui avaient été utilisés aux fins de la mise à niveau de Phénix (version 9.2 de PeopleSoft), car il a été estimé que les 2 projets étaient d’une complexité comparable. Cela dit, ces critères n’ont pas été repris de manière cohérente dans les documents relatifs au projet, ce qui pourrait conduire à une mauvaise interprétation ou à une mauvaise exécution des tests. De plus, les résultats de l’équipe de projet dans les rapports de synthèse pour chaque point de contrôle ont été calculés sur la base des différences par rapport à la mise à niveau de Phénix (version 9.2 de PeopleSoft). À ce moment-là, l’équipe d’audit interne a évalué les tests de validation de la paye en vue de la mise à niveau et n’a fait aucune observation concernant l’utilisation des différences dans les calculs de l’équipe de projet, bien que les critères de réussite soient fondés sur les écarts. Dans le cadre de l’évaluation actuelle de la migration des données, l’audit interne a identifié cela comme une anomalie, car les valeurs reflétaient des montants compensatoires plutôt que les écarts dans leur ensemble. Bien que cette anomalie n’ait pas d’incidence sur les critères de réussite de la migration de la base de données, une distinction entre les termes « écart » et « différence » aurait amélioré la clarté. Enfin, les critères de réussite ont été revus pour la dernière fois en novembre 2020 et il serait utile de les revoir périodiquement pour qu’ils demeurent pertinents, favorisent toujours l’amélioration continue et atténuent les risques.

Bien qu’aucune recommandation n’ait été émise dans le cadre de cette mission d’assurance, des leçons apprises ont été tirées pour être prises en considération dans le cadre de futur projets similaires.

2. Réponse de la direction

Le projet de migration de la base de données du système de paye et de PeopleTools a été livré avec succès le 22 octobre 2024. Depuis la mise en service, plusieurs périodes de paye se sont bien déroulées, ce qui montre que le système de paye s’est stabilisé.

La direction a examiné le présent rapport – Audit de la validation de la paye : migration de la base de données de Phénix – et fournit la réponse suivante sur la base de son évaluation de la mission d’audit interne.

La direction est d’accord avec les leçons apprises suggérées dans le présent rapport. Puisque la rédaction du présent rapport s’est achevée après la mise en service du projet, les leçons apprises ont été documentées et communiquées à la haute direction de SPAC. Elles ont également été inclus dans le portail sur leçons apprises de SPAC, où elles peuvent être examinées et adoptées par d’autres au sein du Ministère.

En ce qui concerne la leçon apprise C, les termes « écart » et « différence » ont été définis; les définitions ont été documentées, puis communiquées aux Opérations aux fins d’examen et d’adoption. En 2021, cette méthodologie a été utilisée pour la mise à niveau de Phénix (version 9.2 de PeopleSoft), où les équipes de projet et d’audit interne ont évalué la méthodologie et les résultats. Dans le cadre du projet, le terme « écart » a été utilisé pour toutes les évaluations de validation de la paye au niveau de l’employé, et le terme « différence » n’a été utilisé que pour les totaux récapitulatifs des bruts à nets. Si cet audit donne des résultats différents, c’est peut-être parce que les totaux calculés sont basés sur des hypothèses faites par l’équipe d’audit interne qui ne correspondent pas aux définitions de projet convenues.

L’équipe de projet a recommandé d’utiliser le terme « écart » pour tous les calculs, comme il est indiqué à la leçon apprise C. Cette information a été transmise à la direction de SPAC, qui favorisera une interprétation et une application communes des calculs, pour garantir que la définition des résultats est clairement définie et documentée de manière cohérente.

Pour conclure, nous tenons à remercier l’équipe d’audit interne pour sa collaboration et les leçons apprises qu’elle a dégagées tout le long de sa mission.

3. Contexte

À titre d’administrateur de la paye et des pensions, SPAC administre la paye de plus de 400 000 employés dans plus de 100 ministères, organismes et sociétés d’État qui utilisent le système de paye Phénix. Le Ministère fournit également des services-conseils complets en rémunération et du soutien direct à la clientèle à quelque 270 000 de ces employés; il fournit également un soutien et un leadership techniques de bout en bout pour toutes les applications liées à la paye.

À l’heure actuelle, Phénix est fondé sur la version 9.2 du logiciel PeopleSoft d’Oracle, la base de données DB2 d’International Business Machines Corporation (IBM) et la plateforme de développement PeopleTools d’Oracle. IBM ayant annoncé qu’elle ne soutiendrait plus la version actuelle de sa base de données à partir de mars 2022, le gouvernement du Canada avait négocié avec IBM et obtenu que l’entreprise prolonge son service de soutien jusqu’en avril 2025. De plus, Oracle a annoncé qu’elle cesserait de prendre en charge PeopleTools au-delà de la version actuelle sur la base de données IBM existante.

Étant donné que l’absence de soutien de la part des fournisseurs entraîne un risque élevé de vulnérabilités en matière de sécurité et de dégradation des services qui a une incidence sur la capacité de SPAC à verser une paye exacte et en temps opportun à ses employés, et afin d’atténuer le risque associé au vieillissement des systèmes de technologie de l’information, SPAC a lancé le projet de migration de la base de données du système de paye et de PeopleTools (ci-après appelé le « projet ») sous la direction de la Direction générale des solutions du portefeuille de Gestion du capital humain. Il s’agit d’un projet technique qui comprend la migration de la base de données du système de paye Phénix de DB2 vers une nouvelle plateforme de base de données prise en charge, Oracle, ainsi que la mise à niveau de la plateforme de développement, PeopleTools. Le projet a commencé en avril 2022 et devait durer 2,5 ans.

Le projet comprend la gouvernance, la mobilisation des parties prenantes et les tests. Plus précisément, les tests sont effectués tout le long du cycle de vie du projet; ils se composent de différentes phases et de différents cycles, chaque cycle de tests portant sur un cycle de paye réalisé sur plusieurs semaines. Les tests de validation de la paye sont un élément du processus de test global qui vise à confirmer qu’après la migration, le système de paye produira des résultats semblables. En d’autres termes, il s’agit de vérifier que le chèque de paye d’un employé est produit de la même manière dans les 2 bases de données.

L’équipe de projet a prévu de mener 4 cycles de validation de la paye (V1, V2, V3 et V4), ainsi qu’un cycle d’urgence supplémentaire (V5) au cas où des problèmes critiques surviendraient au cours de l’un des cycles précédents (voir l’Annexe D pour les cycles et leurs objectifs). Tous les cycles seront évalués par rapport aux critères de réussite qui ont été approuvés dans le cadre de la mise à niveau de Phénix (version 9.2 de PeopleSoft) en 2016 (voir l’Annexe E pour les critères de réussite).

L’équipe de projet a fait appel à Gartner, Inc. (Gartner) pour fournir des services liés à l’ensemble du projet, y compris un soutien tiers, indépendant, d’évaluation comparative et d’assurance de la valeur. Gartner a plus particulièrement effectué des évaluations comparatives pour 4 cycles de validation de la paye, qui visaient le cycle V1B plutôt que le cycle V1, afin de s’assurer que les problèmes du cycle précédent avaient été résolus. En outre, bien que Gartner avait commencé son évaluation du cycle V4, il n’a pas été en mesure de terminer son travail car son contrat est arrivé à échéance.

La migration de la base de données de Phénix vers Oracle a eu lieu le 22 octobre 2024, et il n’est pas possible de revenir à DB2.

4. Focalisation de la mission d’assurance

Étant donné que Gartner n’a pu terminer son évaluation comparative du cycle V4 en raison de la fin de son contrat, la Direction générale des solutions du portefeuille de Gestion du capital humain a demandé que l’équipe d’audit interne fournisse des services d’assurance pour le cycle V4^{Note de bas de page 1}. Des écarts importants ayant été constatés en raison des différentes manières dont les 2 bases de données triaient l’information, l’équipe de projet a obtenu l’approbation de gouvernance appropriée pour annuler le cycle V4 et à procéder au cycle V5, soit le cycle d’urgence.

4.1. Objectif

L’objectif de cette mission d’assurance était d’évaluer, avant la migration, l’efficacité du processus des tests de validation de la paye, ainsi que les résultats du rapprochement des traitement de paye exécutés à partir de la base de données actuelle et de la nouvelle base de données.

4.2. Portée

La mission d’assurance a permis d’évaluer si le cycle de validation de la paye V5 avait été exécuté du 15 juillet 2024 au 10 octobre 2024, conformément au plan de test de la mise à niveau du projet.

Cette mission n’a pas évalué la stratégie de test de la mise à niveau du projet qui avait été utilisée pour les tests de validation de la paye car elle l’avait déjà été dans le cadre de l’audit interne de la mise à niveau de Phénix (version 9.2 de PeopleSoft). De même, les autres tests relatifs à la migration, comme les tests d’intégration des systèmes, les tests de régression et les tests d’acceptation par les utilisateurs n’étaient pas visés par la mission.

La période couverte par la mission d’assurance s’étendait de juillet 2024 à octobre 2024.

4.3. Secteur d’intérêt, critères et méthodologie

Le secteur d’intérêt, les critères et la méthodologie de cette mission d’assurance sont présentés dans l’Annexe C.

Cette mission d’assurance a été menée conformément aux Normes internationales pour la pratique professionnelle de l’audit interne.

5. Observations détaillées et leçons apprises

5.1. Rôles, responsabilités, obligations de rendre compte et pouvoirs

Les rôles, les responsabilités, les obligations de rendre compte et les pouvoirs relatifs aux tests de validation de la paye ont été largement définis et documentés. Le Navigateur de projet de SPAC décrit concrètement les rôles du propriétaire fonctionnel, du promoteur du projet, du chef de projet et du gestionnaire de projet. Dans le cadre du projet global, ces rôles, responsabilités, obligations de rendre compte et pouvoirs ont été attribués à des postes et à des personnes spécifiques, comme il est indiqué dans divers documents de projet, tels que la charte de projet.

En outre, les rôles et responsabilités liés à l’ensemble des tests relatifs à la migration, y compris les tests de validation de la paye (par exemple, le chef de test, le responsable fonctionnel et les testeurs de projet), ont été décrits dans le plan de test. Ces rôles et responsabilités ont été communiqués à l’équipe de projet de diverses manières, notamment lors de réunions d’équipe, et ont été généralement compris par les parties impliquées.

Pour le cycle V5, bien que les rôles et les responsabilités de la ou des personnes qui prennent la décision de passer chaque point de contrôle du cycle des tests de validation de la paye n’aient pas été entièrement documentés, ils ont été communiqués et compris par l’équipe de projet. Dans la pratique, le responsable fonctionnel ou le gestionnaire de projet sont chargés de prendre les décisions relatives aux points de contrôle (consultez le 5.2 Processus relatif aux points de contrôle pour des informations supplémentaires). De plus, le gestionnaire de projet consulte l’équipe de projet sur l’état des points de contrôle, les résultats et d’autres questions pertinentes durant les réunions sur l’état d’avancement du projet, qui ont lieu environ 3 fois par semaine. Certains problèmes, comme les écarts importants dus à des différences de traitement entre les 2 bases de données, sont portés à la connaissance du propriétaire fonctionnel ou de la gouvernance, selon le cas. En outre, les problèmes transmis à la gouvernance sont documentés dans les notes relatives aux décisions. Cela dit, la documentation du projet ne décrit pas complètement les circonstances où il faut s’adresser au propriétaire fonctionnel ou à la gouvernance avant de prendre une décision relative aux points de contrôle.

Leçons apprises

(A) Les rôles et les responsabilités de la ou des personnes qui prennent la décision de passer chaque point de contrôle du cycle des tests de validation de la paye, ainsi que les procédures de transmission au propriétaire fonctionnel ou à la gouvernance devraient être documentés dès le début des tests.

5.2 Processus relatif aux points de contrôle

Le plan de test de la mise à niveau du projet décrit le but et les objectifs des tests de validation de la paye, l’approche à l’égard des tests et l’approche relative à la validation des résultats, y compris le processus relatif aux points de contrôle. L’équipe de projet s’est servi des points de contrôle, une pratique exemplaire qui consiste à diviser les tests en des étapes plus petites. À chacun de ces points de contrôle, les décideurs se réunissent pour examiner les tests et décider, sur la base de critères précis et de l’information disponible à ce moment-là, s’il faut continuer, arrêter, suspendre, recycler ou apporter des modifications. Une fois qu’il a été décidé de passer un point de contrôle, on ne revient généralement pas sur les étapes précédentes et la progression s’effectue de manière linéaire. Une telle approche permet de s’assurer que les décisions sont prises dans un objectif clair, de manière à permettre une évaluation structurée et de réduire le risque de revenir à des étapes antérieures, tout en simplifiant les processus et en maintenant le rythme vers l’atteinte de l’objectif final.

Dans l’ensemble, le processus relatif aux points de contrôle pour les tests de validation de la paye se déroulait comme prévu. Plus précisément, la validation de la paye – V5, comme les cycles précédents, devait compter 10 points de contrôle (consultez la Figure 1 : Cycles de validation de la paye V5 et V5B). Dans le cas du cycle V5, aucun problème n’a été décelé pour les points de contrôle 1 à 4, 7 et 8.

Les problèmes et leurs répercussions des 4 points de contrôle restant sont les suivantes :

Point de contrôle 5

Au cours du point de contrôle 5, un problème de production a été repéré dans les bases de données DB2 et Oracle et, conformément aux procédures établies, l’équipe de production de Phénix, a pris en charge la résolution de ce problème. Comme les 2 bases de données ont produit des résultats similaires et qu’il a été jugé que les écarts dans les montants s’expliquaient, l’équipe de projet est passée au point de contrôle suivant.

Point de contrôle 6

Au début du point de contrôle 6, un autre problème a été soulevé; ce qui a incité l’équipe de projet à ouvrir un billet de service auprès d’Oracle. En parallèle, un environnement identique a été créé; le nom du cycle de l’environnement original est resté le même (V5) et le cycle du nouvel environnement a été nommé V5B. L’équipe de projet a ainsi pu faciliter la résolution du problème tout en franchissant les autres points de contrôle du cycle V5. Cela a également permis à l’équipe de de bénéficier de la flexibilité nécessaire pour revenir ultérieurement au cycle V5B afin d’évaluer, de tester et de valider une solution au problème.

Après une enquête plus approfondie, l’équipe de projet a découvert que le problème était causé par une erreur de codage. Elle n’est donc pas allée plus loin avec le billet de service ouvert auprès d’Oracle et a plutôt modifié le codage au début du point de contrôle 6 du cycle V5B.

Point de contrôle 9

Au point de contrôle 9, l’équipe de projet a repéré une autre erreur de codage qu’elle a corrigée immédiatement. Par la suite, l’équipe a présenté les résultats actualisés du point de contrôle 9, soit le point de contrôle 9.2, avant de passer au point 10.

Point de contrôle 10

Au point de contrôle 10, l’équipe de projet a repéré une autre erreur de codage dans la manière dont les 2 bases de données présentaient leurs données de fin de cycle. Elle a corrigé l’erreur sur-le-champ. Par la suite, l’équipe a présenté des résultats actualisés pour le point de contrôle 10 qui contenaient les données mises à jour et qui ont été appelés « point de contrôle 10 rajusté ».

En ce qui concerne le cycle V5B, une fois le codage corrigé au début du point de contrôle 6B, l’équipe de projet a achevé ce cycle en passant les uns après les autres les points de contrôle, de 6B à 10B. L’équipe de projet a informé celle de l’audit interne qu’aucun autre problème n’avait été rencontré durant le cycle V5B.

Figure 1 : Cycles de validation de la paye V5 et V5B

En outre, les approbations verbales ou écrites pour chaque point de contrôle du cycle V5 ont été fournies en temps opportun (consultez les 5.1 Rôles, responsabilités, obligations et pouvoirs pour des informations supplémentaires). Cela dit, la décision de franchir le point de contrôle n’a pas été documentée et conservée de manière cohérente et formelle en tant que ressource d’information à valeur opérationnelle qui soutiendrait la réalisation du projet.

Leçons apprises

(B) La décision de franchir chaque point de contrôle devrait être documentée et conservée de manière formelle en tant que ressource d’information à valeur opérationnelle pour soutenir la réalisation du projet.

5.3. Résultats des tests de validation de la paye

Le plan de test de la mise à niveau du projet décrit l’approche relative à la validation des résultats, qui comprend la méthodologie de l’analyse des écarts et des seuils pour répondre aux critères de réussite (consultez les 5.4 Critères de réussite pour la validation de la paye et l’Annexe E pour des informations supplémentaires).

Pour effectuer son évaluation, l’équipe d’audit interne a demandé les dossiers justificatifs détaillés de chaque point de contrôle, qui sont spécifiques à un moment précis et ne peuvent être reproduits automatiquement après coup. En ce qui concerne le cycle V5, l’équipe de projet a initialement produit et fourni ces dossiers à l’équipe d’audit interne pour 9 des 10 points de contrôle. En raison des problèmes rencontrés au point de contrôle 6, les dossiers justificatifs détaillés n’ont pas été initialement produits par l’équipe de projet. En début septembre 2024, l’équipe d’audit interne a expliqué à l’équipe de projet qu’en l’absence de ces dossiers, elle ne pourrait fournir d’assurance sur le cycle V5. Après plusieurs discussions, l’équipe de projet a décidé de restaurer les 2 bases de données à un état antérieur, de refaire le point de contrôle 6, puis de préparer les dossiers justificatifs détaillés pour ce point de contrôle, qu’elle a fournis le 4 octobre 2024. Compte tenu de cela, l’équipe d’audit interne a mis en place des procédures supplémentaires pour confirmer la restauration des bases de données; qui s’est avérée exacte et complète.

Avec tous les dossiers justificatifs détaillés requis, les résultats des tests de validation de paye, aux 10 points de contrôle du cycle V5, ont été évalués et rapprochés des résultats de l’équipe de projet pour voir s’il y avait des écarts au niveau des montants. De plus, les résultats de l’équipe de projet dans les rapports de synthèse pour chaque point de contrôle étaient conformes au plan de test de la mise à niveau de cette équipe. Enfin, l’audit interne a constaté que ce cycle répondait aux critères de réussite. Les tableaux 1 et 2 présentent les écarts au niveau des montants aux différents points de contrôle et selon les résultats des critères de réussite, respectivement.

Tableau 1 : Cycle V5 des tests de validation de la paye – écarts à chaque point de contrôle

Point de contrôle	Gains	Autres gains	Retenues	Impôts	Êcart net
1	0,00 $	354,20 $	1 957,41 $	1 611,46 $	3 923,07 $
2	957,71 $	2 337,15 $	3 409,68 $	2 445,51 $	9 150,05 $
3	0,00 $	394,07 $	2 735,48 $	1 004,25 $	4 133,80 $
4	0,00 $	363,40 $	440,98 $	128,07 $	932,45 $
5	0,00 $	12 279,65 $	2 126,91 $	9 377,18 $	23 783,74 $
6	53 628,21 $	187 630,81 $	10 927,26 $	13 825,82 $	266 012,10 $
7	53 628,21 $	213 712,42 $	25 148,38 $	20 501,94 $	312 990,95 $
8	65 379,05 $	213 647,60 $	28 822,74 $	19 558,92 $	327 408,31 $
9.2	88 880,73 $	218 036,85 $	29 143,04 $	19 836,58 $	355 897,20 $
10 rajusté	53 870,28 $	42 819,51 $	6 768,48 $	14 805,01 $	118 263,28 $

Tableau 2 : Résultats des critères de réussite du cycle V5

Critères de réussite	Le critère est-il respecté?	Pourcentage de chèques où il y a un écart	Nombre de chèques qui ne respectent pas le seuil
Le montant de la paye brute varie dans une fourchette de +/- 0,03 $ pour 99 % des chèques.	oui	99.99%	66 chèques
Le montant de la paye nette varie dans une fourchette de +/- 0,03 $ pour 95 % des chèques.	oui	99.95%	234 chèques
Pour les chèques restant (5 %) :	non	s/o	s/o
Le montant de l’impôt retenu varie de +/- 3,00 $ pour 4 % des chèques.	oui	99.98%	105 chèques
Le seuil n’est pas respecté pour 1 % des chèques et la différence est explicable.	oui	99.97%	129 chèques
Le montant des retenues varie de +/- 1,00 $ pour 4 % des chèques.	oui	99.98%	151 chèques
Le seuil n’est pas respecté pour 1 % des chèques et la différence est explicable.	oui	99.98%	83 chèques
Un écart net inexpliqué sera toléré pour 0,01 % des chèques.	oui	0.0041%	19 chèques

De plus, bien que l’équipe de projet ait recommandé le cycle V5B comme solution aux fins de la transition vers la production, elle a choisi de préparer les dossiers justificatifs du point de contrôle 6B, mais pas ceux des 4 autres points de contrôle du cycle (points de contrôle 7B à 10B). Bien que l’équipe du projet disposait d’autres options pour produire ces dossiers, comme une restauration des bases de données, elle a décidé de ne pas prendre cette voie en raison de contraintes de budget et de calendrier. Plus particulièrement, l’équipe a estimé que le risque de rencontrer des problèmes dans ce cycle était faible, étant donné que les résultats des tests pour le cycle V5 correspondaient à ceux de l’équipe d’audit interne. En outre, comme il aurait fallu environ 8 heures par point de contrôle pour préparer les dossiers requis, l’équipe de projet a décidé d’affecter ses ressources à d’autres tâches du chemin critique du projet. Ainsi, l’équipe d’audit interne ne peut donner l’assurance que le cycle V5B répond aux critères de réussite.

5.4 Critères de réussite pour la validation de la paye

En mai 2023, le promoteur du projet et le propriétaire fonctionnel du projet ont accepté que le projet adopte les mêmes critères de réussite pour la validation de la paye que ceux utilisés pour la mise à niveau de Phénix (version 9.2 de PeopleSoft), car il a été jugé que les 2 projets étaient d’une complexité comparable. Les critères de réussite pour la validation de la paye sont présentés à l’Annexe E.

Les critères de réussite approuvés pour la validation de la paye n’ont pas été reflétés de manière cohérente dans les documents relatifs au projet. Par exemple, le plan de test de mise à jour du projet définit des montants de paye nette et brute, ainsi que des seuils d’impôts et de retenues différemment des critères de réussite approuvés. Ces incohérences pourraient conduire à une mauvaise interprétation ou à une mauvaise application des tests.

De plus, les résultats de l’équipe de projet dans les rapports de synthèse pour chaque point de contrôle ont été calculés sur la base des différences par rapport à la mise à niveau de Phénix (version 9.2 de PeopleSoft). À ce moment-là, l’équipe d’audit interne a évalué les tests de validation de la paye en vue de la mise à niveau et n’avait fait aucune observation concernant l’utilisation des différences dans les calculs de l’équipe de projet, bien que les critères de réussite soient fondés sur les écarts. Dans le cadre de l’évaluation actuelle de la migration des données, l’audit interne a identifié cela comme une anomalie, car les valeurs reflétaient des montants compensatoires plutôt que les écarts dans leur ensemble. Bien que cette anomalie n’ait pas d’incidence sur les critères de réussite de la migration de la base de données, une distinction entre les termes « écart » et « différence » aurait amélioré la clarté puisque l’équipe du projet utilise ces termes de manière interchangeable.

Enfin, les critères de réussite n’ont pas été examinés depuis novembre 2020. Une révision périodique des critères, comme les valeurs seuils établies, garantirait leur pertinence continue ou soutiendrait des améliorations continues, telles que les progrès en matière d’analyse des données. En outre, les critères devraient être examinés périodiquement afin d’atténuer les risques. Par exemple, au point de contrôle 7 du cycle V5, les résultats des tests de validation de la paye ont dépassé le seuil de tolérance acceptable pour un écart inexplicable. Ces écarts ont par la suite été expliqués et, en fin de compte, le cycle V5 a été jugé conforme aux critères de réussite. Néanmoins, cela a démontré que même si les critères visent à évaluer l’efficacité globale du cycle dans son ensemble, des évaluations périodiques pourraient fournir des informations précieuses. En particulier, les résultats de chaque étape peuvent identifier des risques qui peuvent ne pas être apparents lors de la communication des critères de réussite uniquement à la fin du cycle.

Leçons apprises

(C) Les critères de réussite pour la validation de la paye doivent être documentés de manière cohérente dans les documents relatifs au projet afin de favoriser une interprétation et une exécution communes des tests. De plus, il devrait être précisé, dans les documents relatifs au projet, que les résultats doivent être calculés en fonction des écarts et non des différences.

(D) Les critères de réussite pour la validation de la paye devraient être examinés périodiquement pour s’assurer de leur pertinence continue, pour soutenir les améliorations continues et pour atténuer les risques.

6. Conclusion

Dans l’ensemble, l’équipe d’audit interne a conclu que le processus de test de validation de la paye ainsi que les résultats du rapprochement des cycles de paye effectués à la fois à partir de la base de données actuelle et de la nouvelle base de données étaient largement efficaces pour le cycle 5. N’étant pas en mesure d’obtenir d’éléments probants, l’équipe d’audit interne ne peut exprimer une conclusion pour le cycle V5B.

Bien qu’aucune recommandation n’ait été émise dans le cadre de cette mission d’assurance, des leçons apprises ont été tirées pour être prises en considération dans le cadre de futur projets similaires.

7. Remerciements

En conclusion, nous souhaitons remercier l’équipe de projet de la Direction générale des solutions du portefeuille de Gestion du capital humain pour le temps qu’elle nous a consacré et les renseignements qu’elle nous a fournis dans le cadre de notre mission.

8. Annexes

Les éléments suivants sont des annexes au présent rapport d'audit.

Dans cette section :

• Annexe A : Sigles et abréviations
• Annexe B : Lexique
• Annexe C : Secteur d’intérêt, critères et méthodologie
• Annexe D : Cycles de validation de la paye et leur objectif
• Annexe E : Critères de réussite pour la validation de la paye qui ont été approuvés

Annexe A : Sigles et abréviations

BDPAER

Bureau du dirigeant principal d’audit, d’évaluation et de gestion du risque

Gartner

Gartner, Inc.

IBM

International Business Machines Corporation

Projet

Projet de migration de la base de données du système de paye et de PeopleTools

SMA

Sous-ministre adjoint

SPAC

Services publics et Approvisionnement Canada

Annexe B : Lexique

Différence

Résultat de la soustraction d’un nombre ou d’un montant d’un autre nombre ou montant.

Écart

La valeur absolue de la différence.

Navigateur de projet

Cadre de gestion de projet de SPAC qui comporte 5 phases, qui sont constituées d’une série d’activités de gestion de projet et de produits livrables qui doivent être achevés. Chaque phase mène à un point de contrôle, qui est en fait un point de décision à franchir avant de passer à la phase suivante.

Plateforme de développement

Logiciel utilisé pour développer, adapter et configurer une application.

Processus relatif aux points de contrôle

Approche structurée de la gestion de projet qui consiste à diviser un projet en phases ou en étapes distinctes, jalonnées de points de décision (points de contrôle) auxquels les progrès sont évalués pour déterminer si le projet doit se poursuivre ou s’il doit être modifié ou arrêté.

Services d’assurance^{Note de bas de page 2}

Examen objectif des éléments probants visant à fournir une évaluation indépendante des processus de gouvernance, de gestion des risques et de contrôle de l’organisation. Il peut s’agir par exemple de missions financières; de missions relatives au rendement, à la conformité, à la sécurité des systèmes; ou de diligence raisonnable.

Seuil

Point où une chose se produit, commence à se produire ou change.

Tests de validation de la paye

Approche permettant de traiter la paye dans un environnement de test au moyen de données réelles, puis de comparer les résultats du calcul du montant brut au montant net pour les employés dont les données sont dans la base de données DB2 et ceux dont elles sont dans la base de données d’Oracle.

Tolérance

Limite ou variation admissible dans les mesures de données.

Valeur absolue

La distance d’un nombre à zéro, que ce nombre soit positif ou négatif.

Annexe C : Secteur d’intérêt, critères et méthodologie

Le processus de validation de la paye s’est déroulé comme prévu selon les critères suivants :

• les rôles, les responsabilités, les obligations de rendre compte et les pouvoirs sont définis, documentés, communiqués et compris
• le processus relatif aux points de contrôle s’est déroulé comme prévu, et consiste notamment à fournir les approbations en temps opportun
• les résultats du traitement de la paye dans la future base de données respectaient les écarts et les seuils établis

Méthodologie

• Mener des entrevues avec l’équipe de projet et le personnel responsable des opérations de la paye ainsi que d’autres parties prenantes, au besoin.
• Examiner et analyser les documents pertinents disponibles, y compris le plan de test de même que la liste des tâches d’exécution et les résultats du traitement de la paye.
• Évaluer les résultats des tests de validation de la paye aux 10 points de contrôle, à partir de la base de données actuelle et de la nouvelle, y compris catégoriser les écarts et effectuer une analyse des seuils, puis comparer ces résultats à ceux obtenus par l’équipe de projet.

Annexe D : Cycles de validation de la paye et leur objectif

Cycles de validation de la paye et leur objectif

Cycle	But
V1 et V1B	S’assurer que les montants des chèques de paye sont exacts.
V2	S’assurer que les modifications ou les corrections apportées après les tests d’intégration des systèmes ou du lancement de la mise à jour fiscale n’ont pas d’incidence sur l’exactitude des chèques de paye.
V3	S’assurer que les changements apportés aux versions standards et non standards n’ont pas d’incidence sur l’exactitude des chèques de paye.
V4	S’assurer que les changements apportés aux versions standards et non standards n’ont pas d’incidence sur l’exactitude des chèques de paye avant la date de déploiement.
V5 et V5B	Cycles de secours au cas où des problèmes critiques survenus au cours d’un cycle précédent doivent être corrigés, puis soumis à d’autres tests.

Annexe E : Critères de réussite pour la validation de la paye qui ont été approuvés

Un comité spécial de sous-ministres adjoints composé de représentants de SPAC, du Secrétariat du Conseil du Trésor, d’Emploi et Développement social Canada et de l’Agence du revenu du Canada a été spécifiquement chargé, en tant que représentants de l’employeur, de fixer les niveaux de tolérance et les seuils de validation de la paye à respecter pour la mise à jour de Phénix (version 9.2 de PeopleSoft). Ces recommandations ont été approuvées par un conseil de sous-ministres adjoints chargé de l’acceptation par les utilisateurs de PeopleSoft 9.2 le 5 novembre 2020, et approuvées pour être utilisées aux fins des tests de validation de la paye par le promoteur du projet et le propriétaire fonctionnel du système, en mai 2023.

Les critères de réussite sont les suivants :

• le montant de la paye brute varie dans une fourchette de +/- 0,03 $ pour 99 % des chèques
• le montant de la paye nette varie dans une fourchette de +/- 0,03 $ pour 95 % des chèques
  • sur les 5 % de chèques restant, le montant de l’impôt retenu varie de +/- 3 $ sur 4 % d’entre eux; sur 1 % de chèques restant, ce montant se situe en dehors du seuil et la différence est explicable
  • sur les 5 % de chèques restant, le montant des retenues varie de +/- 1 $ sur 4 % d’entre eux; sur 1 % de chèques restant, ce montant se situe en dehors du seuil et la différence est explicable
• un écart net inexpliqué sera toléré jusqu’à 0,01 % pour les chèques

Informations sur le droit d'auteur

© Sa Majesté le Roi du chef du Canada, représenté par le ministre des Travaux publics et des Services gouvernementaux, 2025.

Audit de la validation de la paye - Migration de la base de données de Phénix.

No de cat. P4-171/2025F-PDF (fichier PDF, français)

International Standard Book Number (ISBN) : 978-0-660-77641-5

No de cat. P4-171/2025E-PDF (fichier PDF, anglais)
ISBN : 978-0-660-77640-8