Audit du développement des systèmes de technologie de l’information

Version traduite. En cas de divergence entre le présent texte et le texte anglais, la version anglaise a préséance.

Rapport définitif : Mars 2020

Table des matières

• Liste des acronymes
• Résumé
• A : Introduction
  • Contexte
• B : Constatations, recommandations et réponses de la direction
  • Cadre de gestion
  • Définition des processus de développement des systèmes de TI
  • Mesures de contrôle du développement des systèmes de TI
  • Établissement des coûts
  • Analyse comparative fondée sur le sexe et le genre plus
• C : Conclusion
• Annexe A : À propos de l’audit
  • Objectif de l’audit
  • Portée de l’audit
  • Méthode d’audit
  • Déclaration de conformité
• Annexe B : Critères d’audit
• Annexe C: Carte de pointage

Liste des acronymes

ACSG+

analyse comparative fondée sur le sexe et le genre plus

AQ

assurance de la qualité

ASPC

Agence de la santé publique du Canada

COBIT

objectifs de contrôle de l’information et des technologies associées

CT

Conseil du Trésor

DPI

dirigeant principal de l’information

DSGI

Direction des services de gestion de l’information

EAU

essai d’acceptation par l’utilisateur

LNM

Laboratoire national de microbiologie

SC

Santé Canada

SPC

Services partagés Canada

TI

technologies de l’information

Résumé

Qu’est-ce que nous avons examiné?

Services partagés Canada (SPC) gère l’infrastructure des technologies de l’information (TI) du gouvernement du Canada en fournissant une gamme de services essentiels aux opérations gouvernementales, notamment la livraison de courriels, des centres de données et des services de technologie de réseau et de milieu de travail. Les administrateurs généraux de chaque ministère et organisme sont responsables de la gestion efficace des TI au sein de leur ministère, notamment les données, les applications, l’accès des utilisateurs aux appareils et aux profils, ainsi que la sécurité infonuagique et des TI.

Santé Canada et l’Agence de la santé publique du Canada (ASPC) ont établi un partenariat de services partagés qui comprend les fonctions de gestion de l’information et des technologies de l’information (TI). Le dirigeant principal de l’information (DPI) du Ministère et de l’Agence est responsable de l’administration de la gouvernance et de la planification des TI, ainsi que des stratégies connexes. L’objectif consiste à favoriser un régime solide de TI en établissant une structure de gouvernance efficace, en intégrant la planification des TI à la planification ministérielle globale et en harmonisant les stratégies avec celles du gouvernement du Canada.

Nous avons examiné l’efficacité des contrôles de gestion sur le développement des systèmes de TI. Ceci a compris la subdélégation au DPI de la responsabilité du développement des systèmes de TI par le Conseil du Trésor. Nous n’avons pas examiné les prises de décisions concernant les systèmes à développer, la gestion des projets relatifs à ces systèmes, ni l’élimination des systèmes. Ces aspects pourraient être abordés dans le cadre d’audits futurs.

Pourquoi le développement de systèmes informatiques est-il important?

Les technologies de l’information (TI) sont au cœur de presque tous les aspects des activités de Santé Canada et de l’ASPC. Le Ministère et l’Agence comptent 264 applications opérationnelles actives et 1 136 autres systèmes de TI, sites Web statiques et dépôts. Selon son Plan d’investissement de 2018 à 2023, Santé Canada prévoit investir 103,09 M$ pour financer 22 projets de GI et de TI. De même, le Plan d’investissement de l’ASPC de 2019 à 2022 prévoit 10 projets de GI et de TI, totalisant 15,06 M$.

La fonction de TI permet et soutien une prestation plus efficace des programmes. Les retards et les complications peuvent nuire à la prestation de programmes destinés aux Canadiens.

Qu’est-ce que nous avons constaté?

Nous avons constaté l’absence de certaines mesures de contrôle clés en matière de gouvernance et d’assurance de la qualité, ce qui limite l’efficacité du développement des systèmes de TI pour l’Agence et le Ministère. Nous avons constaté que Santé Canada et l’ASPC se conforment à la plupart des exigences de l’ensemble des politiques du CT de 2018. Toutefois, l’absence d’un cadre de gestion pour le développement des systèmes de TI signifie que les rôles et les responsabilités, ainsi que la subdélégation des responsabilités du DPI à d’autres directions générales, n’ont pas été définis. Contrairement à la politique du CT, le DPI ne préside pas actuellement de conseil d’examen de l’architecture ministérielle et n’approuve pas systématiquement la composante TI de tous les plans, stratégies, initiatives, projets, approvisionnements et demandes d’autorisation de dépenses du Ministère.

Nous avons trouvé un guide détaillé de la méthode « en cascade » pour développer des systèmes de TI. Nous n’avons pas trouvé de guide semblable pour la méthode de développement « agile » récemment adoptée pour le Centre des solutions de la DSGI, la Division des services informatiques des sciences du Laboratoire national de microbiologie (LNM) et la Division de l’informatique des affaires de la Direction générale des produits de santé et des aliments (DGPSA).

La majorité des mesures de contrôle du développement des systèmes de TI documentés dans le guide de la méthode « en cascade » ont fonctionné comme prévu. Toutefois, des lacunes importantes ont été relevées dans les mesures de contrôle utilisées pour les exigences opérationnelles, les analyses d’options, les essais d’acceptation par l’utilisateur (EAU), l’assurance de la qualité et les processus de sécurité des TI. Dans de nombreux cas, nous avons constaté que les procédures obligatoires de développement des systèmes de TI n’étaient pas suivies systématiquement ou ne respectaient aucune norme de qualité.

Nous avons constaté que les membres du personnel ne possédaient pas la formation officielle requise en matière d’analyse comparative fondée sur le sexe et le genre plus (ACSG+) pour prendre des décisions éclairées quant aux domaines qui pourraient bénéficier de la prise en considération de l’ACSG+.

Dans l’ensemble, nous avons formulé cinq recommandations qui vont améliorer conjointement l’efficacité du développement des systèmes de TI à Santé Canada et à l’ASPC.

A : Introduction

Contexte

Santé Canada et l’Agence de la santé publique du Canada (ASPC) utilisent 264 applications opérationnelles actives et 1 136 autres systèmes de TI, sites Web statiques et dépôts pour aider à la prestation de programmes et aux opérations internes. Compte tenu de l’importance des systèmes de TI pour remplir les mandats de Santé Canada et de l’ASPC, de pratiques solides de développement de systèmes de TI sont nécessaires pour s’assurer que les solutions opérationnelles reposant sur les TI répondent aux besoins des propriétaires de systèmes et sont conformes aux instruments de la politique du CT en matière de technologie de l’information (TI) et de sécurité du gouvernement

La Politique sur la gestion des technologies de l’information du Conseil du Trésor, mise à jour en 2018, précise que le dirigeant principal de l’information (DPI) du Ministère est chargé d’« approuver la composante TI de l’ensemble des stratégies, des plans, des initiatives, des projets, des approvisionnements et des demandes d’autorisation de dépenses du ministère » et de présider un conseil pour confirmer que les nouveaux systèmes de TI cadrent bien avec l’architecture du gouvernement du Canada.

La plupart des activités de la composante TI ont lieu à la Division du Centre des solutions de la Direction des services de gestion de l’information (DSGI), qui relève directement du DPI de Santé Canada et de l’ASPC. La pratique actuelle n’interdit pas aux directions générales d’entreprendre des travaux de développement de systèmes de TI à l’interne ou de faire appel à des fournisseurs externes.

La plupart des services d’infrastructure et de soutien opérationnel pour les systèmes de TI ministériels sont hébergés par Services partagés Canada (SPC) dans les centres de données du gouvernement du Canada, mais d’autres systèmes ministériels sont hébergés dans le réseau scientifique du LNM. La Division des services d’informatique scientifique du LNM gère et soutien le développement de systèmes. Il existe un autre réseau, à la DGPSA, appelé « environnement de haute résilience » (EHR). La Division de l’informatique des affaires de la DGPSA dirige la plupart, mais non la totalité, du développement de systèmes de cet environnement.

En 2018, la DSGI a mis à jour son guide de méthodologie pour le développement de systèmes. Le guide précise que ses processus sont obligatoires pour tous les projets de développement de logiciels, soient ceux développés à l’interne, disponibles sur le marché ou externalisés. Elle reconnaît toutefois que les petits projets n’exigent pas le même niveau de rigueur que celui prévu dans le guide et qu’il serait possible d’appliquer un sous-ensemble de la méthodologie de développement de systèmes de TI.

Les meilleures pratiques et les normes du cadre de contrôle du développement des systèmes de TI ont été codifiées dans les directives de l’industrie des TI. Le modèle principal est le COBIT (objectifs de contrôle de l’information et des technologies associées), ainsi que le guide d’audit de la technologie globale du Cadre de référence international des pratiques professionnelles (IPPF). Le COBIT définit les rôles, les responsabilités et les pratiques en matière de gouvernance et de contrôle des systèmes d’information dans le but d’aligner les systèmes de TI avec les besoins opérationnels.

À l’aide des processus de facilitation du modèle COBIT pour la gouvernance et la gestion des TI d’entreprise, nous avons vérifié la mesure dans laquelle les processus de développement des systèmes de TI et les principales mesures de contrôle ont été définis et mis en œuvre à Santé Canada et à l’ASPC.

B : Constatations, recommandations et réponses de la direction

Cadre de gestion

La Politique sur la gestion de la technologie de l’information du CT de 2007 précise que le DPI est responsable d’agir à titre de représentant des TI de leur ministère auprès du Secrétariat du CT. En 2018, la Politique a été mise à jour pour rendre le DPI responsable de la gestion des TI, y compris la planification, l’acquisition, la conception et la mise en œuvre des systèmes de TI. Il doit, entre autres :

• approuver la composante TI de tous les plans, stratégies, initiatives, projets, acquisitions et demandes d’autorisation de dépenser;
• assurer que les données et les applications soient sécurisées, fiables et dignes de confiance, de même que les systèmes et les réseaux ministériels qui ne sont pas fournis par SPC;
• présider un conseil d’examen de l’architecture ministérielle dont le mandat consiste à examiner et approuver l’architecture de tous les services, les projets, les initiatives, les approvisionnements et les stratégies ministériels et d’en assurer l’harmonisation avec la vision d’architecture du gouvernement du Canada.

La Directive du CT de décembre 2018 a ajouté des responsabilités au DPI, notamment l’élaboration, à des fins d’approbation par l’administrateur général, de structures de gouvernance ministérielles qui favorisent un processus décisionnel efficace en matière de TI. Il convient de noter que ces deux instruments de politique seront remplacés le 1er avril 2020 par la Politique sur les services et le numérique du CT, ainsi que par la Directive sur les services et le numérique qui l’accompagne. Le Politique et la Directive de 2020 conserveront toutefois les exigences susmentionnées tout en accroissant d’autres responsabilités du DPI.

Nous avons constaté que Santé Canada et l’ASPC ne se conformaient pas aux exigences clés de l’ensemble des politiques du CT énumérées ci-dessus. Nous avons trouvé un protocole d’accord entre la DSGI et la Division des services d’informatique scientifique du LNM pour le développement de systèmes de TI et pour la production de rapports sur les résultats des travaux de développement au DPI. Cependant, nous n’avons trouvé aucune entente en place avec d’autres directions générales, malgré le fait que le développement des systèmes de TI s’effectue dans tout le Ministère et l’Agence par l’entremise de fournisseurs de services externes sous une supervision évidemment minimale de la part du DPI. Il n’avait aucun cadre de gestion approuvé qui précise si cette répartition des activités de TI est permise ni qui décrit en détail les mécanismes d’approbation, de surveillance ou de gestion des risques dans le cadre de cette répartition des activités. Contrairement à la Politique du CT, le DPI n’a pas présidé de conseil d’examen de l’architecture ministérielle ni approuvé la composante TI de tous les plans, stratégies, initiatives, projets, acquisitions et demandes d’autorisation de dépenser ministériels.

Nous avons constaté qu’il existait des processus d’examen et d’approbation pour assurer que les nouvelles applications ne compromettraient pas le réseau de la CPS et qu’elles s’harmoniseraient avec la stratégie globale de TI. Nous avons trouvé peu de rapports au DPI sur les activités de TI réalisées à l’extérieur de la direction du DPI de la Direction générale des services de gestion, mais qui relevaient tout de même de sa responsabilité en vertu de la Politique du CT. Même si le DPI peut être mis au courant des activités de développement de systèmes de TI dans le cadre des processus de contrôle de la gestion des projets, les documents de contrôle et les tableaux de bord de la gestion des projets ne comportent pas de rapports au DPI dans les domaines relevant de sa responsabilité.

En conclusion, Santé Canada et l’ASPC ne se conforment pas à tous les éléments de l’ensemble des politiques du CT de 2018. Il manque un cadre de gestion pour le développement des systèmes de TI. Ce cadre permettrait d’assurer la conformité aux politiques du CT et de préciser les rôles et les responsabilités de ceux qui peuvent entreprendre le développement de systèmes de TI. Ce cadre de gestion décrirait plus en détail la façon dont le DPI doit être tenu au courant des activités à l’intérieur et à l’extérieur de Santé Canada et de l’ASPC et préciserait les formes de surveillance des risques, d’examen et de processus d’approbation mises en place pour s’assurer que les systèmes de TI sont conformes à l’orientation stratégique du Ministère et du gouvernement du Canada en matière de TI.

Recommandation 1

Le dirigeant principal de l’information devrait élaborer un cadre de gestion qui documente :

• les responsabilités en matière de développement de systèmes de TI;
• l’étendue des responsabilités qui sont déléguées;
• les exigences en matière de rapports relativement aux responsabilités déléguées.

Puisque le développement des TI concerne toutes les directions générales, le DPI devrait partager ce cadre de gestion approuvé avec les comités exécutifs de l’ASPC et de Santé Canada, ainsi qu’avec les clients à des fins d’information.

Réponse de la direction

Définition des processus de développement des systèmes de TI

Une méthodologie de développement de logiciels fournit une méthode documentée et reproductible de développement de logiciels. Santé Canada et l’ASPC ont recours à deux méthodologies. Le modèle « en cascade » se décompose en une série d’étapes de processus séquentielles linéaires et chaque étape dépend des livrables de l’étape précédente. Le modèle « agile » utilise une méthode plus itérative, fondée sur l’évolution des exigences et des solutions opérationnelles, dans le cadre d’une collaboration entre le propriétaire du système et l’équipe de développement afin de convenir de solutions évolutives en TI et de les mettre au point conjointement.

Nous nous attendions à ce que Santé Canada et l’ASPC disposent de modèles de processus de développement de systèmes, de lignes directrices, de normes techniques, de méthodologies de développement et de modèles de livrables, ainsi que d’un cadre d’assurance de la qualité (AQ).

Nous avons trouvé des documents d’orientation sur les processus, des modèles de livrables et des mesures clés de contrôle bien définies, ainsi qu’un cadre d’assurance de la qualité (AQ) pour la présentation de rapports au DPI dans le cadre de la méthode « en cascade ». Ces éléments s’alignent aux rôles, aux responsabilités et aux points de contrôle clés définis dans le cadre du processus de développement et sont aussi conformes aux pratiques exemplaires de l’industrie, tels que définies dans la version 5 de COBIT. Nous avons toutefois constaté que les points de contrôle clés de la méthode « agile » ne sont pas définis. L’absence d’un guide de la DSGI sur la méthode « agile » pour les projets de Santé Canada et de l’ASPC peut mener à des rôles et des responsabilités imprécis pour tous les intervenants, ainsi qu’un manque de mesures de contrôle et d’approbations appropriées tout au long du processus.

En conclusion, nous avons trouvé des guides documentés détaillés sur le développement de systèmes de TI pour la méthode « en cascade » à Santé Canada et à l’ASPC, mais pas pour la méthode « agile ».

Recommandation 3

Le dirigeant principal de l’information devrait définir les principales mesures de contrôle des processus pour la méthode « agile ».

Réponse de la direction

Mesures de contrôle du développement des systèmes de TI

Le cadre du cycle de développement des systèmes (CDS) de la DSGI établit les processus et les activités séquentielles que doivent suivre les concepteurs et les développeurs de systèmes. Chaque étape du processus de CDS comporte des livrables obligatoires qui fournissent à l’équipe de développement les spécifications de conception et de système requises pour informer les étapes de développement subséquentes.

Nous avons choisi un échantillonnage dirigé de cinq projets de développement de systèmes de TI en nous basant sur cinq critères pour couvrir une variété de projets différents. Ces critères sont les suivants : la mise en œuvre récente ou en cours du projet, l’importance relative du projet en jours ou en dollars, le gestionnaire de projet (DSGI et directions générales), l’hôte du système (CPS, EHR et le réseau scientifique) et la méthodologie de développement utilisée (agile ou en cascade).

Nous nous attendions à ce que les projets de développement de systèmes de Santé Canada et de l’ASPC comprennent des exigences opérationnelles définies et approuvées. Nous nous attendions aussi à ce que le processus en matière d’exigences opérationnelles appuie une traçabilité des besoins opérationnels, des exigences précises, ainsi que des conceptions et spécifications techniques.

Nous avons constaté qu’un des projets échantillonnés, cogéré par la Division de l’informatique des affaires de la DGPSA et le Centre des solutions de la DSGI, a été retardé en raison de l’absence de mesures de contrôle appropriées au cours du processus d’établir les exigences opérationnelles. Le gestionnaire de projet de la DGPSA et l’analyste des activités de la DSGI ont apporté plusieurs changements aux exigences sans avoir recours aux mesures de contrôle appropriées pour obtenir l’approbation et l’accord des intervenants de projets concernés. Les changements à la portée ont causé des retards qui n’ont pas été bien compris ni appréciés par le promoteur du projet.

Nous avons aussi constaté qu’un contrat dirigé par un client n’avait pas été examiné avec la même rigueur que les projets internes. L’absence de supervision ministérielle de la gestion des projets de TI a été un facteur qui a contribué à la hausse des coûts d’un projet de la DGPSA confié à une source externe, qui sont passés de 110 000 $ à 680 000 $.

Nous nous attendions à ce que le processus obligatoire d’analyse des options soit mené pour tous les nouveaux projets de développement de systèmes de TI, afin de répondre le mieux possible aux besoins des clients. Dans deux des quatre projets testés relativement à l’analyse des options, nous avons constaté que les mesures de contrôle étaient inefficaces. Un projet géré par la Division de l’informatique des affaires de la DGPSA n’avait pas fait l’objet d’une analyse des options. Un deuxième projet, cogéré par la Division de l’informatique des affaires de la DGPSA et le Centre des solutions de la DSGI, comportait des éléments d’information incomplets ou manquants qui étaient essentiels à l’analyse des options. Cette analyse des options a aussi été effectuée trois ans après le lancement du projet. Le résultat était que les architectes de solutions informatiques n’ont pas pris en considération certains éléments essentiels, comme les contraintes, les limites de la technologie et les normes, au cours de l’étape de conception. Nous avons constaté que l’inefficacité des mesures de contrôle de l’analyse des options a contribué à certains problèmes techniques et à des retards au cours des étapes d’essai et de mise en œuvre des deux projets.

Nous nous attendions à ce que les essais des systèmes confirment le respect des exigences opérationnelles et en matière de qualité. Ces procédures comprennent des plans définis relativement à l’essai d’acceptation par l’utilisateur (EAU), des tests élémentaires et les résultats prévus reliés aux exigences opérationnelles, des tests exécutés dans le même environnement d’infrastructure technique que la production et les résultats de l’EAU approuvés par le propriétaire du système. Nous avons constaté des incohérences dans la définition de l’acceptation et de l’approbation de l’EAU par le propriétaire d’un projet à l’autre.

Nous nous attendions à ce que les risques soient gérés pour atténuer leurs incidences sur les projets de développement de systèmes. Ceci comprend démontrer que des livrables de sécurité informatique étaient produits aux étapes appropriées du processus de développement des systèmes afin de cerner efficacement les vulnérabilités et d’atténuer les menaces.

Nous avons constaté que les contrôles obligatoires liées à la sécurité des TI conçues pour fournir une assurance raisonnable de la détermination des vulnérabilités et des risques en matière de sécurité informatique et pour la mise en œuvre de mesures d’atténuation, sont en grande partie inefficaces. Nous avons constaté que pour la majorité des projets échantillonnés, les équipes ont commencé les projets sans être au courant ou préparés pour les risques liés au développement de systèmes informatiques de TI, tels que les options de conception de solutions, la complexité du projet, les vulnérabilités en sécurité informatique et les besoins en matière d’identification et d’authentification des utilisateurs.

Nous nous attendions à trouver des preuves de l’existence d’un programme complet d’assurance de la qualité (AQ) pour le développement de systèmes informatiques. Nous avons constaté que la fonction d’AQ décrite dans le guide de développement n’avait pas été mise en œuvre au cours des dernières années. La fonction d’AQ se limitait principalement à l’exécution de tests d’AQ sur des outils de productivité commerciaux et de tests sur des systèmes d’exploitation dans un environnement de laboratoire contrôlé. Un processus d’AQ est nécessaire pour assurer que les projets effectuent les processus et procédures requis en matière de développement des systèmes de TI et de sécurité des TI, et qu’ils produisent les livrables obligatoires pour fournir une assurance adéquate que les risques liés au développement des systèmes de TI sont suffisamment atténués.

Dans l’ensemble, nous avons constaté que de nombreuses mesures de contrôle de développement des systèmes de TI fonctionnaient généralement comme prévu. Des lacunes ont toutefois été relevées dans les exigences opérationnelles, l’analyse des options, l’EAU, la sécurité des TI et les activités d’AQ. Une fonction d’AQ plus rigoureuse permettrait d’atténuer ces lacunes.

Recommandation 3

Le dirigeant principal de l’information doit mettre en œuvre des processus obligatoire d’assurance de la qualité qui fournissent une supervision et la production de rapports sur la mise en œuvre des mesures de contrôle obligatoires pour le développement de systèmes, y compris les exigences opérationnelles, l’analyse des options, l’essai d’acceptation par l’utilisateur et la sécurité des TI.

Réponse de la direction

Établissement des coûts

Nous nous attendions à ce que le processus de développement de systèmes de TI de Santé Canada et de l’ASPC facilite l’établissement de coûts raisonnables pour la prise de décisions à chaque niveau du projet, y compris l’élaboration les directives et les coûts à un niveau de précision acceptable à mesure que le projet progresse.

Nous avons trouvé des méthodes d’établissement des coûts qui reflètent adéquatement le niveau de détail du projet. Aux étapes préalables à la planification, la portée du projet et les options technologiques sont encore incertaines. Il convient donc d’adopter une approche qui, en général, permet d’évaluer la taille du projet, notamment en le comparant à des projets antérieurs. À la fin de l’étape de planification, ces incertitudes devront être en grande partie levées et l’établissement des coûts peut être aussi précis que la détermination des rôles, le temps à consacrer au projet et les coûts correspondants.

Nous avons constaté que des modèles étaient disponibles pour déterminer les types de coûts à inclure, documenter les calculs de coûts et fournir un format commun. Nous avons constaté que les coûts de haut niveau ont été précisés au cours des premières étapes du projet et que des coûts détaillés ont été déterminés avant que le projet n’entre dans son étape d’exécution. Lorsque la DSGI participait aux projets, elle y contribuait soit en estimant le niveau d’effort pour les plans des projets techniques ou en examinant les coûts des projets. Les coûts des projets ont été présentés à la haute direction dans le cadre du processus d’approbation des projets et ils ont ensuite fait l’objet d’un rapport continu dans les tableaux de bord des projets pour permettre à la haute direction de surveiller les écarts entre les estimations budgétaires et les dépenses.

Deux des projets échantillonnés ont présenté des difficultés quant au processus de planification qui n’a pas permis de déterminer pleinement la nature et l’étendue des travaux à effectuer, ce qui a entraîné l’affectation de ressources insuffisantes aux projets. La cause fondamentale semble être une sous-estimation du travail à effectuer, plutôt qu’un problème d’établissement des coûts des ressources qui y étaient attribuées. La recommandation de renforcer le processus d’AQ devrait améliorer cet aspect par l’inclusion de normes d’établissement des coûts d’un projet dans le cadre de l’AQ du développement des systèmes de TI.

Dans l’ensemble, nous avons constaté un processus efficace d’établissement des coûts pour la prise de décisions à chaque étape du projet.

Analyse comparative fondée sur le sexe et le genre plus

La politique du portefeuille de la Santé du gouvernement du Canada consiste à utiliser l’analyse comparative fondée sur le sexe et le genre plus (ACSG+) pour élaborer, mettre en œuvre et évaluer ses recherches, sa législation, ses politiques, ainsi que ses programmes et services. Plus particulièrement, la politique exige que tous les membres du personnel soient responsables d’utiliser l’ACSG+ dans le cadre de leur travail, le cas échéant.

Nous nous attendions à ce que le Ministère et l’Agence aient intégré l’ACSG+ dans ses activités de développement de systèmes de TI et aient fourni la supervision, la formation et les outils nécessaires pour assurer sa mise en œuvre.

Nous avons constaté que le personnel de la DSGI n’avait pas suivi de formation sur l’ACSG+ et qu’il n’était donc pas en mesure de rendre un jugement bien informé sur l’utilisation appropriée de l’ACSG+. Nous n’avons trouvé aucune analyse documentée indiquant à quel moment l’ACSG+ était appropriée ou non dans le cadre des processus de développement de systèmes de TI.

Dans l’ensemble, nous avons constaté que les membres du personnel n’avaient pas la formation officielle requise pour prendre des décisions éclairées quant aux domaines qui pourraient bénéficier de la prise en considération de l’ACSG+.

Recommandation 4

Le dirigeant principal de l’information devrait sensibiliser le personnel à l’ACSG+ et tenir compte de l’ACSG+ dans la conception de solutions d’affaires informatiques.

Réponse de la direction

C : Conclusion

Le but de cet audit est de fournir une assurance raisonnable que les mesures clés de contrôle du développement des systèmes de TI étaient en place et qu’elles fonctionnaient bien.

Nous avons conclu qu’il manque certaines mesures de contrôle clés en matière de gouvernance et d’assurance de la qualité, ce qui limite l’efficacité du développement des systèmes de TI pour l’Agence et le Ministère.

Nous avons constaté que Santé Canada et l’ASPC se conforment à la plupart des exigences de l’ensemble des politiques du CT de 2018. Toutefois, l’absence d’un cadre de gestion pour le développement des systèmes de TI signifie que les rôles et les responsabilités, ainsi que la subdélégation des responsabilités du DPI à d’autres directions générales, n’ont pas été définis. Contrairement à la politique du CT, le DPI ne préside pas actuellement de conseil d’examen de l’architecture ministérielle et n’approuve pas systématiquement la composante TI de tous les plans, stratégies, initiatives, projets, approvisionnements et demandes d’autorisation de dépenser du Ministère.

Nous avons trouvé un guide détaillé de la méthode « en cascade » pour développer des systèmes de TI. Nous n’avons pas trouvé de guide semblable pour le Centre des solutions de la DSGI, la Division des services informatiques des sciences du LNM et la Division de l’informatique des affaires de la DGPSA pour la méthode de développement « agile » récemment adoptée.

La majorité des mesures de contrôle du développement des systèmes de TI documentés dans le guide de la méthode « en cascade » ont fonctionné comme prévu. Toutefois, des lacunes importantes ont été relevées dans les mesures de contrôle utilisées pour les exigences opérationnelles, aux analyses d’options, aux essais d’acceptation par l’utilisateur (EAU), à l’assurance de la qualité et aux processus de sécurité des TI. Dans de nombreux cas, nous avons constaté que les procédures obligatoires de développement des systèmes de TI n’étaient pas suivies systématiquement ou ne respectaient aucune norme de qualité.

Nous avons constaté que les membres du personnel manquaient une formation officielle requise sur l’ACSG+ pour prendre des décisions éclairées quant aux domaines qui pourraient bénéficier de la prise en compte de l’ACSG+.

Dans l’ensemble, nous avons formulé quatre recommandations qui amélioreront conjointement l’efficacité du développement des systèmes de TI à Santé Canada et à l’ASPC.

Annexe A : À propos de l’audit

Objectif de l’audit

Le but de cet audit est de fournir une assurance raisonnable que les principales mesures de contrôle relatives au développement de systèmes de TI étaient en place et qu’elles fonctionnaient bien.

Portée de l’audit

La portée de l’audit comprend les processus de gestion pour les projets de développement de systèmes de TI de Santé Canada et de l’ASPC qui sont en cours ou qui ont été récemment terminés.

La portée de l’audit ne comprend pas la gestion de l’infrastructure utilisée pour héberger les systèmes de TI de Santé Canada et de l’ASPC. Elle ne comprend pas non plus les exigences de la Politique sur la gestion des projets et de la Politique de planification des investissements – Actifs et services acquis du SCT, puisque celles-ci seront couvertes par d’autres audits.

Méthode d’audit

L’audit a été effectué conformément à la Politique sur l’audit interne du gouvernement du Canada par l’examen et la collecte d’un nombre suffisant de données pertinentes pour offrir un niveau raisonnable d’assurance à l’appui de la conclusion de l’audit.

Les critères d’audit ont été tirés de la version 5 du COBIT, du Cadre international de référence des pratiques professionnelles (IPPF), du Guide d’audit de la technologie globale (GTAG) et des Conseils en matière de sécurité des technologies de l’information du Centre de la sécurité des télécommunications Canada (CST).

La méthode retenue comprenait les éléments suivants, sans s’y limiter :

• des entrevues avec les propriétaires de systèmes et le personnel de développement et de soutien des systèmes de TI;
• un examen des documents, des politiques, des normes, des lignes directrices et des cadres pertinents;
• une mise à l’essai des livrables de développement de systèmes de TI des projets échantillonnés;
• une analyse des constatations tirées des entrevues, de la documentation et des essais détaillés.

Le projet était de nature collaborative et les résultats ont été approuvés par les parties concernées.

Déclaration de conformité

Cet audit a été réalisé conformément aux Normes internationales pour la pratique professionnelle de l’audit interne. Il est validé par les résultats du programme d’amélioration et d’assurance de la qualité du Bureau de l’audit et de l’évaluation.

Annexe B : Critères d’audit

Audit du développement des systèmes de technologie de l’information critères d’audit :

1. Un cadre de gestion facilite le développement des systèmes de TI de Santé Canada et de l’ASPC.
2. Des processus de développement de systèmes de TI et des mesures de contrôle clés pour Santé Canada et l’ASPC ont été définis.
3. Les mesures de contrôle clés de développement de systèmes de TI fonctionnent comme prévu.
4. Les processus de développement de systèmes de TI facilitent l’établissement de coûts raisonnables pour la prise de décisions à chaque point de contrôle du projet.
5. Les questions relatives à l’ACSG+ sont systématiquement prises en compte dans les projets de développement de systèmes de TI.

Annexe C : Carte de pointage

Audit du développement des systèmes de technologie de l’information

Critère	Cote de risque	Conclusion	Rec no.
Cadre de gestion	3	Il n’y a pas de cadre de gestion approuvé qui documente les responsabilités en matière de développement des systèmes de TI et la délégation aux autres parties du ministère, ainsi que les contrôles clés pour assurer que les normes minimales de qualité technique ont été satisfaites. Il y a un risque que le DPI ne soit pas toujours au courant des activités à travers et à l’extérieur de SC et ASPC. Il y a aussi un risque que les systèmes de TI ne soient pas toujours conformes avec la direction stratégique en TI du Ministère et du gouvernement du Canada.	1
Processus et contrôles clés définis	2	L’absence d’un guide « agile » de la DSGI pour les projets de SC et l’ASPC entraîne le risque que les rôles et les responsabilités de tous les intervenants ne soient pas clairs, ainsi qu’un manque de contrôles et d’approbations appropriés tout au long du processus.	2
Contrôles de développement des systèmes de TI	3	Les contrôles de développement des systèmes de TI fonctionnent généralement comme prévu. Toutefois, des lacunes ont été cernées dans les exigences opérationnelles, l’analyse des options, les EAU, la sécurité de la TI et les activités d’AQ. Ceci entraîne des risques de délai de projet et d’augmentation des coûts. Une fonction AQ renforcée atténuera ces risques.	3
Coûts	2	Les coûts étaient définis et sont devenus plus précis en moyen de définition accrue et d’incertitude affaiblie. Il y a un risque que les projets sous-estiment le niveau d’effort exigé.
Analyse comparative fondée sur le sexe et le genre plus	1	Il y a risque que la DSGI n’adaptera pas ses systèmes de façon appropriée si elle n’intègre pas l’ACSG+ dans les processus pertinents.	4
Définitions des niveaux de risque : Risque minime Risque mineur Risque moyen Risque important Risque majeur