Services à la clientèle de la TI - Processus relatif au développement et à la maintenance des applications

Rapport de vérification définitif
Le 20 juin 2012

Table des matières

Version traduite. La version anglaise doit prévaloir en cas d'incohérence.

Sommaire

La vérification visait à déterminer si Santé Canada s'est doté d'un processus pour mettre en œuvre et maintenir des applications en technologie de l'information (TI). La vérification a été effectuée conformément à la Politique sur la vérification interne du Conseil du Trésor et aux Normes internationales pour les méthodes professionnelles de vérification interne. Des procédures suffisantes et appropriées ont été suivies et des preuves ont été recueillies pour appuyer la conclusion de la vérification.

Le budget en matière de gestion de l'information/technologie de l'information (GI-TI) pour le développement des applications au sein de l'administration centrale pour l'exercice 2011-2012 s'élevait à 15,4 millions de dollars. Pour la même période de temps, le développement des applications et la maintenance régionaux des TI ont été signalés à 0,6 million de dollars cependant, la plupart du développement des applications est contracté à l'extérieur du Ministère. Les directions générales ont affecté 49,4 millions de dollars pour les projets de développement des applications, ce qui a été approuvé dans le Plan d'investissements de Santé Canada pour 2011-2012.

Globalement, même si le Ministère détient des pratiques pour développer des applications et les maintenir, cette activité tirera avantage du renforcement de la gouvernance, de la gestion des risques et des contrôles internes.

En conséquence des changements importants à l'ensemble du gouvernement du Canada, ainsi qu'à l'intérieur de Santé Canada, la Direction des services de gestion de l'information reconnaît le besoin de réévaluer son modèle de gouvernance et de prestation de la TI en matière du développement des applications et de la maintenance. Étant donné que le Processus de planification des investissements du Ministère possède un modèle de gouvernance approuvé accompagné de pratiques de gestion des projets approuvées et documentées, le Ministère serait bien servi si les applications, soit en cours de développement ou planifiées, étaient  rendues dans le cadre du Processus de planification des investissements. L'utilisation de ce processus pour appuyer le développement des applications assurera : que les mécanismes de surveillance pour veiller à ce que les contrôles entourant le développement et la maintenance des applications de la TI reflètent précisément les objectifs du Ministère; que les rôles et les responsabilités sont bien définis; que les mécanismes relatifs aux points de contrôle sont utilisés pour atténuer les risques fonctionnels et pour entraîner une meilleure discipline autour de la gestion de projet.

Le portefeuille des applications de la TI pour Santé Canada doit être fondé sur la compréhension de l'environnement organisationnel fonctionnel, de l'identification de la demande actuelle et à venir et d'une analyse des coûts et des risques associés au développement de solutions, y compris la maintenance. Auparavant, cette analyse a été effectuée de façon cloisonnée - chaque direction générale respectivement.  Cependant, certaines fonctions qui traversent plusieurs directions générales et le Ministère tireraient avantage de documenter un ensemble de base d'information qui, collectivement, pourrait être utilisé pour identifier les besoins organisationnels, les priorités d'investissements et pour définir l'architecture organisationnelle de la TI.  Les modèles devraient fournir un langage commun pour le Ministère; soutenir l'identification d'applications dupliquées, réutilisables et partageables; fournir une base pour examiner objectivement les investissements de la TI; permettre une prestation plus rentable et opportune des services de la TI par l'entremise d'un entrepôt de normes, de principes et de gabarits (tel qu'attendu dans le cadre d'une approche de cycle de vie du développement des systèmes).

L'établissement de la méthode du cycle de vie du développement des systèmes du Ministère, y compris des contrôles et une orientation mise à jour combiné avec l'exploitation de la capacité régionale en complément au siège social, servira à renforcer l'approche organisationnelle tout en assurant que les applications sont développées et maintenues avec efficacité et efficience.

Des accords de niveau de services en matière de maintenance pour les applications nouvelles et existantes fourniront une assurance aux directions générales sur la continuité des activités aux directions générales ainsi que le développement d'indicateurs de rendement par la Direction des services de gestion de l'information. Même si la Direction des services de gestion de l'information réduit activement le nombre d'applications au sein du Ministère, elle devra gérer des nouvelles priorités en matière d'applications en liaison avec des systèmes de maintenance existants afin de rendre les meilleurs services de la TI.

La direction a souscrit aux cinq recommandations et a fourni un plan d'action détaillé qui, une fois mis en œuvre, renforcera le développement et la maintenance des applications à Santé Canada.

A - Contexte

En tant que ministère à vocation scientifique doté d'un effectif professionnel, Santé Canada doit se doter d'applications, d'outils et d'une infrastructure qui faciliteront l'exécution de son mandat réglementaire et politique.

La mise en œuvre efficace de processus de développement et de maintenance des applications est essentielle à la réussite des projets en matière de technologie de l'information (TI). Les méthodes de développement et de maintenance des applications doivent fournir des processus favorisant la création de solutions d'entreprise productives, opportunes et économiques. Les services englobent souvent des conseils en architecture, la planification des capacités et la planification, le développement et la mise à l'essai des réseaux. (voir annexe C)

Activités de développement d'applications

  1. Définir l'architecture de la solution
  2. Définir les exigences (y compris l'utilisation de prototypes)
  3. Concevoir le cadre de la solution
  4. Mettre au point la solution
  5. Valider la solution par rapport aux exigences
  6. Déployer la solution
  7. Offrir un soutien continu

Le budget consacré aux activités de gestion de l'information et de technologie de l'information (GI-TI) de l'administration centrale pour l'exercice 2011-2012 s'élevait à 79,6 millions de dollars, dont 15,4 millions de dollars ont été alloués au développement et à la maintenance des applications. Les directions générales ont affecté 49,4 millions de dollars pour les projets de développement des applications, ce qui a été approuvé dans le Plan d'investissements et les activités régionales en matière de TI ont été signalées à approximativement 0,6 million de dollars.

Les activités de GI-TI de Santé Canada ont fait l'objet d'une réorganisation majeure entre 2005-2006 et 2006-2007 afin d'appliquer une approche d'entreprise à la gestion de la TI. Cela a permis de regrouper le matériel informatique, les logiciels et les services de TI de Santé Canada sous la responsabilité du sous-ministre adjoint de la Direction générale des services de gestion afin de réaliser des économies. Cette initiative visait à consolider et à recentrer les ressources et les infrastructures de Santé Canada, à définir les normes ministérielles et à repositionner le Ministère de façon à ce qu'il respecte les initiatives de services communs du gouvernement du Canada. Cinq ans plus tard, Santé Canada s'affaire toujours à aplanir les difficultés qui découlent du fait que les directions générales et les régions ont développé leurs propres applications afin de répondre aux exigences en matière de programme. De nombreuses générations de logiciels sont en circulation, comme le logiciel de création de base de données Oracle, ce qui accroît la complexité des opérations. L'Initiative de réduction des applications de la TI mise en œuvre à Santé Canada a permis d'analyser quelque 2 000 applications, dont près de 800 seront archivées ou éliminées.

1. Objectif de la vérification

La vérification vise à déterminer si Santé Canada s'est doté de processus pour mettre en œuvre et maintenir les applications de la TI de manière efficace et efficiente.

2. Portée et méthode

Le processus a été mis en œuvre à Santé Canada dans la région de la capitale nationale ainsi que dans les bureaux régionaux répartis au pays. La vérification s'est limitée aux processus de TI mis en œuvre au moment de la vérification (exercice 2011-2012) et aux données historiques se rapportant aux projets en cours. En plus du travail effectué au sein de la région de la capitale nationale, la méthode a impliqué des visites dans les bureaux régionaux de l'Atlantique, de l'Ontario, du Nord, du Manitoba, de la Saskatchewan, de l'Alberta et de la Colombie-Britannique.

Le cadre SGSI - Socle de la gouvernance des systèmes d'information  (objectifs de contrôle de l'information et des technologies associées) a servi de source de critères de vérification et est présenté à l'annexe A. Il s'agit d'un cadre largement utilisé et promulgué par l'Institution de gouvernance TI. Il définit des objectifs de base en matière de contrôle des applications ainsi que les approches recommandées pour évaluer les objectifs.

La vérification des services à la clientèle de la TI -  Processus relatif au développement et à la maintenance des applications se concentrait sur ce qui suit :

  • Gouvernance et organisation de prestation des services - Un nombre suffisant de mécanismes de surveillance existe pour s'assurer que les contrôles entourant le développement et la maintenance des applications de la TI correspondent adéquatement aux objectifs du Ministère, que les rôles et les responsabilités reflètent un niveau approprié de répartition des tâches, et que des mécanismes de surveillance sont en place pour atténuer les risques fonctionnels.
  • Analyse des besoins en matière d'applications - Santé Canada crée un portefeuille de solutions d'entreprise dans le domaine de la TI en s'appuyant sur une compréhension de l'environnement opérationnel du client, une détermination des demandes actuelles et à venir et une analyse des coûts et des risques associés au développement et à la maintenance d'une solution.
  • Processus relatif au développement et à la maintenance des applications - Le processus relatif au développement et à la maintenance a été conçu afin de répondre au mieux aux besoins des utilisateurs et aux priorités du Ministère, tout en respectant le budget alloué.

La phase d'examen comportait des entrevues avec le personnel de la Direction des services de gestion de l'information (DSGI), le personnel régional des services de gestion de l'information (SGI) et les principaux représentants des clients de la DSGI à l'échelle régionale et nationale. Le processus comprenait une analyse des processus choisis, de la documentation des projets, des procédures d'exploitation et des outils.

3. Énoncé d'assurance

Selon le jugement professionnel du dirigeant principal de la vérification, des procédures suffisantes et appropriées ont été suivies, et des preuves ont été recueillies pour attester de l'exactitude de la conclusion de la vérification. Les constatations et la conclusion de la vérification se fondent sur une comparaison des conditions qui existaient au moment de la vérification et des critères convenus avec la direction. De plus, les preuves ont été rassemblées conformément aux Normes relatives à la vérification interne au sein du gouvernement du Canada et aux Normes internationales pour les méthodes  professionnelles de la vérification interne.

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

1. Gouvernance et organisation de prestation des services

1.1 Orientation stratégique

Critère de vérification : Le Ministère a défini une stratégie en matière d'architecture d'entreprise pour le développement d'applications qui est alignée avec les priorités du Ministère.

À l'intérieur d'une stratégie de gestion des TI d'entreprise, l'identification des applications devant être développées devrait être guidée par les priorités du Ministère et alignée avec ses principes d'architecture. Ces principes sont les règles et les lignes directrices générales établies par le dirigeant principal de l'information pour l'utilisation et le déploiement des ressources de TI et pour former la base pour les décisions futures en matière de TI.

Santé Canada a récemment transmis son orientation stratégique pour le développement des applications par l'entremise du Plan d'investissements. Pour l'exercice 2011-2012, le Plan d'investissements de Santé Canada est composé de 18 projets en matière de technologie de l'information (TI) pour les programmes et de 10 projets en matière de TI pour les services ministériels. La liste a été épurée par rapport à l'exercice 2010-2011 et continuera à être actualisée comme le Ministère continue à trouver le juste équilibre parmi les besoins organisationnels concurrents et les ressources limitées.

L'ensemble des gouvernements fédéraux des États-Unis et de l'Australie, les ministères et les organismes choisissent de développer des solutions en matière de TI qui sont fondées sur les processus organisationnels communs. Ce sujet est venu en grande partie en raison de pressions d'améliorer la satisfaction de la clientèle et la productivité organisationnelle. À un moment donné, par exemple, les modèles étaient produits seulement pour des automatisations particulières et à des fins d'améliorations de processus. Maintenant, la modélisation stratégique dans « l'ensemble de l'entreprise » est de plus en plus fréquente. Cette modélisation permet de mettre une multitude de différents processus en contexte pour indiquer dans quelle mesure ils sont interdépendants. De cette façon, les organismes peuvent réduire le nombre d'applications, les réutiliser et assurer le partage de nouvelles applications. Il serait avantageux d'appliquer les processus organisationnels dans l'ensemble des directions générales afin de confirmer les principes d'architecture et de cibler les investissements dans une série stratégique d'applications.

Recommandation 1

Il est recommandé que le sous-ministre adjoint de la Direction générale des services de gestion, en consultation avec les directions générales clientes, précise une stratégie d'architecture d'entreprise pour le développement des applications.

Réponse de la direction

La direction souscrit à la recommandation.

L'élaboration des modèles de référence organisationnels établira une vision à long terme et décrira les activités de Santé Canada autour des fonctions organisationnelles communes (telles que réglementaires).

Ces modèles feront la promotion de la collaboration ministérielle en établissant l'information de base. Ceci sera l'occasion pour que le Ministère détermine collectivement les priorités des investissements.

1.2 Surveillance de la direction

Critère de vérification : Une surveillance convenable a été établie pour assurer que les applications des TI sont développées et maintenues conformément aux priorités organisationnelles.

Le développement des applications et le maintien ultérieur exige une structure de gouvernance au sein de laquelle des décisions se produisent pour assurer une approche d'architecture d'entreprise, y compris une orientation pour la sélection, la gestion et l'achèvement de projets. La sélection de projet était un processus de bas en haut qui a débuté avec l'approbation d'une courte liste des projets majeurs en matière de TI par les comités exécutifs des directions générales. Cette liste a été soumise aux fins d'examen par le Comité de planification des investissements - directeurs généraux - un forum de consultation sur les questions, processus, projets et activités liés à la planification des investissements. Celui-ci assure la conformité à l'orientation stratégique et à l'alignement aux politiques du Conseil du Trésor. Les membres du Comité sont également chargés de communiquer les décisions en matière de planification des investissements au sein des directions générales.  Le Comité est composé de représentants de chaque direction générale. Les recommandations formulées par celui-ci sont ensuite examinées par le Comité de planification des investissements - sous-ministres adjoints. Celui-ci examine le Plan d'investissements et les recommandations au Comité exécutif. Il assure que les projets sont conformes aux orientations stratégiques et aux politiques du Conseil du Trésor et de Santé Canada. Le Comité est composé de sous-ministres adjoints choisis et il est coprésidé par le contrôleur ministériel et le sous-ministre adjoint de la Direction générale des services de gestion. L'examen et l'approbation finaux sont achevés par le Comité exécutif - l'organe de décision du niveau le plus élevé.

Au sein de la Direction générale des services de gestion (DSGI), le Comité des opérations et de la surveillance agit en tant que point de surveillance pour l'ensemble des activités en matière de TI dans le Ministère, y compris les projets liés au Plan d'investissements. Au moment de la vérification, le Bureau d'exécution des projets de TI était chargé de fournir des fonctions de secrétariat pour ces trois comités de surveillance.

Avant le Processus de planification des investissements, Santé Canada a établi ses priorités en matière de la GI-TI par l'entremise du processus de planification opérationnelle annuel conduisant à un portefeuille de projets connu sous le nom de « Tableau de bord de la GI-TI ».  Même si le personnel des directions générales et régional interviewé comprend clairement l'avantage de la prise de décisions stratégiques sur les investissements en matière de TI par l'entremise du Processus de planification des investissements, ils sont incertains de l'état des projets qui figuraient précédemment dans le Tableau de bord et qui ne sont pas reflétés dans le Plan d'investissements en raison du fait qu'ils passent sous les seuils de planification des investissements. Selon la politique du Conseil du Trésor, les coûts de projets qui dépassent 1 million de dollars doivent être compris dans le Plan d'investissements et il est nécessaire d'effectuer une évaluation de la complexité et des risques des projets afin d'identifier le niveau de surveillance quant à la gestion du projet.  

Actuellement, la gouvernance existante pour le développement des applications ne tient pas compte de ces projets importants en matière de TI qui passent sous les seuils de la planification des investissements. De plus, plusieurs initiatives régionales en matière d'application de la TI ne sont pas couvertes dans la structure de gouvernance actuelle. Puisque le Ministère a développé un processus de gestion des projets axé sur les risques qui comprend des niveaux variés de surveillance par les organes de gouvernance de la planification des investissements, en proportion à la valeur financière, la complexité et le niveau de risque de chaque projet, il serait avantageux de soumettre tous les projets en matière de TI à la rigueur du Processus de planification des investissements.

De plus, il serait important que la DSGI gouverne les applications déployées par l'entremise de stratégies de prolongement, de renforcement, ou de la retraite d'applications. Actuellement, plusieurs de ces activités sont gérées dans le cadre du processus de gestion du changement au sein de la direction de la TI.

Recommandation 2

Il est recommandé que le sous-ministre adjoint de la Direction générale des services de gestion, établisse un cadre de gouvernance pour le développement et la maintenance des applications.

Réponse de la direction

La direction souscrit à la recommandation.

Elle a déjà commencé à utiliser le cadre de planification des investissements et de production de rapports, pour appuyer le développement des applications.

Le Système intégré de planification et de présentation de l'information sur le rendement a été récemment approuvé par le Comité exécutif de Santé Canada.  Ce modèle de gouvernance détermine les exigences organisationnelles communes liées aux projets.

La Direction des services de gestion de l'information renforcera son modèle de gouvernance interne pour la gestion des projets de développement et de maintenance des applications.

La Direction des services de gestion de l'information définira la gouvernance pour le Plan d'investissements et les activités de maintenance des applications.

1.3 Rôles et responsabilités

Critère de vérification : Les responsabilités et la responsabilisation relatives au développement et à la maintenance des applications de TI ont été clairement définies, documentées et comprises.

Un partenariat entre le fournisseur de services, la DSGI, le consommateur et les directions générales permet d'offrir les services de TI et d'en faire usage. Afin d'utiliser les ressources limitées de manière optimale, les ressources de l'administration centrale et des régions doivent comprendre le rôle qu'ils ont à jouer. Une structure doit être mise en place en vertu de laquelle l'expertise en matière de développement et de maintenance peut être optimisée dans l'ensemble du Ministère.

La Direction des services de gestion de l'information a fait l'objet d'un important remaniement et a considérablement évolué. À la suite de l'examen des rôles et des responsabilités mené au début du processus de vérification, on a créé le Programme d'architecture d'entreprise pour définir des normes, effectuer des analyses et prodiguer des conseils visant à adapter les investissements de TI aux orientations opérationnelles en s'appuyant sur une stratégie ministérielle à long terme. Ce groupe fait maintenant l'objet d'un remaniement dans le but d'intégrer l'architecture de la TI à d'autres activités. L'architecte d'entreprise principal relève maintenant du dirigeant principal de l'information. Après être resté vacant pendant quelque temps, le poste de directeur de l'architecture d'entreprise a été doté.

La participation du groupe Participation des clients et gouvernance est un élément de l'approche de la direction en ce qui a trait à la gestion des exigences opérationnelles. Ce groupe doit prodiguer des conseils stratégiques aux directions générales de Santé Canada relativement aux services de GI-TI et aux investissements, y compris le développement de nouvelles applications et les initiatives du Ministère en matière d'infrastructure.

Comme cela a été indiqué précédemment, le Bureau d'exécution des projets doit offrir des services administratifs aux trois comités de surveillance. Le directeur doit également assumer les responsabilités relatives à l'architecture d'entreprise et aux services offerts aux clients du portefeuille. Ces responsabilités doivent être précisées étant donné qu'elles ont été élargies afin d'inclure d'autres fonctions opérationnelles.

Dans l'industrie de la TI, la planification stratégique s'inscrit habituellement dans la sphère conceptuelle de l'architecte et non pas dans la fonction de liaison avec le client. Le client identifie ses besoins, et les services d'architecture conçoivent l'orientation future. La DSGI doit reconstruire sa capacité afin de renforcer la vision architecturale du Ministère, et elle doit surveiller les activités de GI-TI afin qu'elles répondent à cette vision.

Le groupe des services de gestion de l'information régional (SGI) est le fournisseur régional des services de TI et ce groupe relevait du sous-ministre adjoint de la Direction générale des régions et des programmes au moment de la vérification. Étant donné que l'équipe de l'administration centrale relève du sous-ministre adjoint de la Direction générale des services de gestion, les rôles et les responsabilités n'ont pas toujours été clairement définis entre l'administration centrale et les régions. Il faudrait redéfinir les activités de TI « locales » et  « nationales », surtout à la lumière de la mise en œuvre récente des services de TI de l'Agence des Services partagés Canada et de l'entente tripartite qui aura une incidence sur les attentes en matière de prestation de services à la Direction générale de la santé des Premières nations et des Inuits. Bien que les rôles aient été définis au sein de la DSGI, l'équipe de l'administration centrale doit établir une meilleure communication avec le personnel régional des services de gestion de l'information et avec leurs directions générales clientes.

Même si chaque région offre des services de soutien en TI, chacune d'entre elles fonctionne différemment en ce qui concerne la dotation, le maintien en poste, le nombre de postes prévus au budget et le degré de communication entre le personnel de TI et les programmes régionaux. Par exemple, dans une région, les ressources de TI relèvent des services de gestion de l'information tout en étant financées par la Direction générale de la santé des Premières nations et des Inuits en vertu d'un protocole d'entente de trois ans. Une autre région emploie du personnel très qualifié mais sous-utilisé, et une troisième région visitée a permis d'observer comment des ententes locales peuvent favoriser la participation d'employés de TI principaux et subalternes aux projets de l'administration centrale.

Le sous-ministre adjoint de la Direction générale des services de gestion et le dirigeant principal de l'information ont visité plusieurs régions au cours des deux dernières années en vue de discuter de la participation des services de gestion de l'information au développement des applications. Tous les gestionnaires régionaux principaux ont exprimé un intérêt quant à l'élaboration d'une approche relative au développement d'applications qui mettrait mieux à profit les capacités régionales. Les bureaux régionaux ont indiqué qu'ils pourraient offrir une meilleure valeur en adoptant une approche mixte centrale-régionale, étant donné leur compréhension inhérente des processus opérationnels régionaux combinée à leur expertise en TI. En misant sur l'expertise régionale, on pourrait combler les disparités régionales et renforcer la capacité de la DSGI à répondre aux besoins fonctionnels du Ministère.

Les directions générales, sont les propriétaires fonctionnels des applications et doivent travailler avec la DSGI et les services de gestion de l'information régionaux. Une fois le développement d'une application approuvé, les propriétaires fonctionnels (directions générales) doivent définir les besoins fonctionnels et collaborer avec la DSGI afin de satisfaire aux normes architecturales du Ministère. Bien que la DSGI soit responsable de la TI d'entreprise, les directions générales ont acquis, par le passé, une autonomie et une autorité distinctes. Étant donné les capacités réduites de la DSGI, les directions générales ont assuré le développement des applications en acquérant les compétences nécessaires en TI. Ce type de mesures nuit considérablement à la mise en œuvre d'une approche d'entreprise. L'autonomie accrue des directions générales signifie que le personnel de la DSGI et des services de gestion de l'information régionaux ne peut mettre en place une fonction de remise en question visant à assurer le respect des normes relatives au développement des applications.

Une entente formelle, comme un  accord de niveau de services, favorise une communication efficace et la clarification des rôles et des responsabilités entre la TI et les programmes en ce qui concerne les services requis. Ces accords officiels décrivent habituellement tous les services essentiels de TI requis en lien avec les mandats de programme, notamment : les capacités de TI; les niveaux de financement adéquats; l'évaluation du rendement du projet par rapport à la portée; le calendrier; la qualité; les coûts et les critères de risque; ainsi que la présentation de rapports. La surveillance et la présentation de rapports en temps opportun aux clients concernant le respect des niveaux de service facilitent l'harmonisation entre les services de TI et les mandats de programme connexes. La DSGI a des accords de niveau de services en place avec ses clients externes mais elle ne dispose pas d'ententes séparées avec les directions générales.  Contrairement à l'administration générale, certaines régions ont des accords de niveau de services en place.

 Les ministères et organismes utilisent un accord de niveau de services tant pour les services fournis par les ressources internes que ceux qui le sont par des tiers et des partenaires. Parmi les principales raisons qui incitent les ministères et organismes à conclure des accords de niveau de services, notons une amélioration de l'efficacité et de l'efficience en ce qui a trait à la prestation des services et le fait que les accords négociés prévoient des mesures du rendement claires et documentées. Étant donné que les applications de TI en cours de développement peuvent s'appuyer sur le processus de planification des investissements pour les rapports, il ne serait que nécessaire que la DSGI envisage des accords de niveau de services pour capter les besoins de maintenance des directions générales.

Recommandation 3

Il est recommandé que le sous-ministre adjoint de la Direction générale des services de gestion d'élaborer des ententes de niveau de services avec les directions générales pour la maintenance et le soutien des applications.

Réponse de la direction

La direction souscrit à la recommandation.

Selon les normes existantes, la Direction des services de gestion de l'information, en consultation avec les clients à l'intérieur de Santé Canada ou de l'Agence de la santé publique du Canada, examinera toutes les applications et assurera leur catégorisation selon le risque.

La Direction des services de gestion de l'information examinera les normes de services existantes et les mettra à jour afin de répondre aux lacunes.  La norme de niveau de service appropriée sera ensuite identifiée et confirmée avec les propriétaires des applications.

1.4 Suivi et rapport de la direction

Critère de vérification : La direction a mis en place une surveillance propre au développement et à la maintenance des applications de TI pour rendre compte de l'état des objectifs fixés, des objectifs de rendement, de la prestation des solutions et de la satisfaction des clients.

Le Bureau d'exécution des projets de TI doit assurer le suivi des projets et présenter des rapports rédigés à l'aide de l'outil de présentation des renseignements concernant les projets et du formulaire de demande de développement d'applications. Les activités de surveillance comprennent la cueillette de rapports d'étape bimensuels auprès des gestionnaires de projets de la DSGI. Les détails sur l'état d'avancement des projets sont compilés dans un tableau de bord qui sert à étayer les rapports du portefeuille du Plan d'investissements. En plus des exigences concernant la production de rapports sur le Plan d'investissements, qui sont consignées séparément, le Comité des opérations et de la surveillance détermine également les autres projets nécessitant un suivi. Les activités de maintenance sont consignées dans un autre élément de l'outil de présentation de renseignements en lien avec les projets, mais elles ne sont pas inscrites dans le tableau de bord comme le précisent les critères de présentation de rapports de projet.

La surveillance et la gestion des rapports en lien avec le développement et la maintenance des applications sont étroitement liées à des exigences de gestion de projet imposées par le Bureau d'exécution de projets et son mécanisme de déclaration. (voir recommandation 2) La vérification a constaté que la discipline de gestion de projet pour le Plan d'investissements implique les rapports à la direction et une surveillance convenables.

2. Solutions organisationnelles en matière de TI et analyse des besoins

2.1 Évaluation des exigences opérationnelles

Critère de vérification : Les exigences opérationnelles doivent être identifiées, priorisées et maintenues en couvrant la portée complète de tous les besoins organisationnels auxquels on doit répondre.

Le développement d'une nouvelle application doit faire l'objet d'analyses avant qu'une organisation s'en porte acquéreur ou la crée afin de garantir le respect des exigences opérationnelles de manière efficace et efficiente. Il s'agit d'un processus qui couvre la définition des besoins, l'étude d'autres solutions, l'examen de la faisabilité technologique et économique, la réalisation d'une analyse des risques et d'une analyse coûts-avantages et la prise d'une décision finale visant la conception, le développement en partenariat ou l'acquisition d'une application. Toutes ces étapes permettent aux organisations de maximiser le rendement des investissements et d'acquérir et de mettre en œuvre des solutions, tout en appuyant l'entreprise.

La DSGI détient les éléments essentiels pour consigner, gérer et évaluer les exigences opérationnelles, mais n'a pas élaboré de « processus » comme celui qui est décrit ci-dessus. Elle a un cadre de base pour le développement des applications ainsi qu'un ensemble de modèles normalisés qui, une fois regroupés, forment une pratique. Une feuille de calcul (appelée aussi tableau des jalons) donne un aperçu des produits livrables, des responsabilités et des approbations prévues concernant la totalité du cycle d'élaboration des systèmes. Cependant, aucune documentation de processus globale n'a été trouvée. On constate d'ailleurs que deux ensembles de pratiques existent : un relatif aux exigences entourant les nouveaux systèmes et l'autre touchant la maintenance continue.

Les directions générales qui établissent des partenariats avec la DSGI pour développer des applications reçoivent des modèles de l'Unité d'analyse fonctionnelle. Même si la Direction générale est responsable du contenu, la DSGI définit souvent les exigences en collaboration avec les directions générales clientes. Dans certains cas, les directions générales ont recours aux services d'analystes fonctionnels internes ou de fournisseurs externes pour définir les exigences. Malgré tout, on s'attend à ce que les analystes fonctionnels  utilisent les outils et les procédures normalisés, et la DSGI doit veiller au respect des normes avant de passer à l'étape du développement. L'Équipe accès aux marchés valide les demandes de développement d'applications et évalue certains éléments comme la technologie et le financement disponibles afin de déterminer si le projet sera approuvé.

Les vérificateurs ont examiné un échantillon de 13 projets de développement d'applications pour mettre à l'essai l'approche du cycle chronologique. La vérification a révélé que le processus n'est pas toujours clair puisque l'utilisation de modèles normalisés n'est pas uniforme d'un projet à l'autre, cependant, des exercices sur les leçons apprises ont permis de créer et de peaufiner bon nombre de modèles du cycle chronologique de l'élaboration des projets. L'outil de présentation de rapports de projet permet aux gestionnaires de rendre compte des progrès par rapport aux jalons, mais la vérification a permis de constater qu'il n'existe aucun ensemble d'outils de gestion de projet intégré pouvant faciliter l'exécution des projets. Il y a un ensemble d'exigences d'information présentées par le Bureau d'exécution des projets, mais ils ne sont pas regroupés dans un dépôt. La DSGI souligne qu'elle a récemment mis en œuvre un produit d'architecture de système qui pourrait servir à conserver l'information nécessaire. En conclusion, la feuille de calcul servant à détailler les pratiques du cycle chronologique de l'élaboration des systèmes n'est qu'une version provisoire et elle devrait être mise à jour.

Les bureaux régionaux respectent le processus en matière d'exigences opérationnelles à divers degrés. Dans un cas, le processus régional de gestion du changement était facilité par un outil intégré, mais dans la plupart des cas, les vérificateurs n'ont pu observer aucune méthodologie de mise au point formelle. Les bureaux régionaux tireraient parti d'un ensemble d'outils qui leur permettrait de répondre à la fois aux attentes du Ministère et d'offrir des services uniformes dans l'ensemble des régions. (voir la recommandation 4)

2.2 Évaluation du risque

Critère de vérification : Les risques associés aux exigences opérationnelles et à la conception des solutions doivent être identifiés, documentés et analysés.

Il faut évaluer les risques à diverses étapes selon le tableau des jalons du cycle chronologique. Les chartes de projet et les analyses de rentabilisation sont deux exemples de situations où les renseignements relatifs à l'évaluation des risques devraient être détaillés. Le Bureau d'exécution des projets précise que l'allocation des ressources permettant d'effectuer des analyses environnementales et d'aligner les projets avec le reste de l'organisation est une procédure complexe mobilisant plusieurs intervenants dans le but de réaliser des économies, et que cette étape fait partie du processus de gestion des risques.

On s'attendait à ce que les directions générales préparent des analyses de rentabilisation, y compris les évaluations des risques pour appuyer leurs demandes cependant, l'échantillon des projets analysé a dénoncé que seulement quelques-uns d'entre eux en avaient effectué. Par conséquence, les évaluations des risques étaient manquantes dans certains cas.

Le produit final de la Phase de l'analyse fonctionnelle est le documentsur les besoins fonctionnels détaillés.Après examen par les pairs, l'équipe de la TI formule une recommandation proposant de passer à l'étape suivante. Or, les bureaux régionaux n'ont pas adopté de processus d'évaluation des risques et ils profiteraient des conseils offerts par l'administration centrale.

Les principaux risques associés au développement et à la maintenance sont des risques de nature environnementale ou organisationnelle et ne sont pas propres à une application. Par conséquent, il est nécessaire d'adopter une approche d'entreprise globale d'évaluation des risques qui documente les risques ministériels et régionaux conformément à une vision architecturale unique. (voir la recommandation 4)

2.3 Faisabilité des solutions

Critère de vérification : Des études sont effectuées pour examiner la faisabilité des solutions.

L'analyse des options figure au tableau des jalons. Avec l'adoption du Plan d'investissements, l'analyse des options ou de la faisabilité est souvent terminée avant qu'un projet soit approuvé. Certaines directions générales ont plus d'expérience et disposent des capacités à l'interne. Elles ont uniquement recours aux services de la DSGI pour les estimations des coûts. Les analyses de faisabilité sont habituellement comprises dans les analyses de rentabilisation qui sont examinées par la DSGI.

Les vérificateurs ont constaté que seulement certains échantillons de projets examinés contenaient une analyse des options de haut niveau. Dans certains cas, il s'agissait d'un processus d'itération et les options n'étaient pas toutes évaluées dans les délais établis. Par exemple, l'analyse des options du système de données sur le transport médical faisait partie d'un processus continu prévoyant un certain nombre de points de décision pendant toute la durée du projet. La plupart des bureaux régionaux réalisent une étude de faisabilité, mais il n'existe aucun processus établi par l'administration centrale qui les oblige à accomplir cette étape. Lorsque la Direction générale dirige un projet, il est possible qu'aucune analyse de faisabilité ne soit réalisée. (voir la recommandation 4)

2.4 Approbation des commanditaires

Critère de vérification : Le commanditaire organisationnel approuve les exigences opérationnelles et les rapports d'étude sur la faisabilité à des étapes principales prédéterminées.

L'approbation des commanditaires est une étape comprise dans les modèles du tableau des jalons. La DSGI a adopté le nouveau processus d'approbation en fonction des points de contrôle élaboré pour les projets du Plan d'investissements. Ce processus requiert l'approbation d'un responsable à chacune des étapes principales. Dans le cas des projets de petite envergure, la charte de projet comporte habituellement des étapes (analyse des besoins fonctionnels, mise à l'essai, production et acceptation des utilisateurs finaux) nécessitant l'approbation d'un responsable. L'approbation des projets de la DSGI est habituellement inscrite au tableau des jalons du cycle chronologique. Les vérificateurs ont constaté que certains échantillons de projets examinés avaient été approuvés par le propriétaire fonctionnel. Lorsque le projet mobilise plusieurs directions générales, le commanditaire de projet est responsable d'obtenir l'approbation de toutes les unités organisationnelles concernées. Dans les régions, les travaux doivent être approuvés par le directeur régional des services de gestion de l'information. Or, on a observé que dans certains cas, cette étape a été ratée.

Recommandation 4

Il est recommandé que le sous-ministre adjoint de la Direction générale des services de gestion développe des contrôles et une orientation, en consultation avec les autres directions générales, en ce qui concerne les exigences opérationnelles, les évaluations des risques, la faisabilité des solutions et l'approbation.

Réponse de la direction

La direction souscrit à la recommandation.

La Direction a déjà commencé à élaborer des documents d'orientation afin d'améliorer l'élaboration des exigences organisationnelles, des processus organisationnels, des évaluations des risques de la technologie de l'information et la faisabilité des solutions ainsi que la planification des investissements, de la gouvernance et de la surveillance.

De plus, la Direction cherchera à améliorer ces capacités internes afin de fournir des conseils et une orientation continus sur les exigences en matière de développement et de maintenance des applications.  Un remaniement régional de la gestion de l'information et de la technologie de l'information contribuera aussi à une rigueur améliorée.

3. Processus de développement et de maintenance des solutions organisationnelles de la TI

3.1 Processus de développement d'applications

Critère de vérification : Le développement et la maintenance des applications sont effectués de manière à mieux répondre aux besoins des programmes et aux priorités du Ministère. Ces étapes respectent le processus d'élaboration, d'homologation, de gestion de la transition et de la maintenance des applications ou de la gestion du changement.

Les applications devraient être développées ou conçues conformément aux besoins fonctionnels en couvrant la conception d'applications, l'inclusion convenable de contrôles d'applications et d'exigences de sécurité et conformément aux normes.

La feuille de calcul du cycle de vie de l'élaboration des systèmes (tableau des jalons) décrit les produits, les responsabilités et les autorisations prévues. Les éléments couvrent le développement, du choix du projet à la mise en œuvre de la solution fonctionnelle. Étant donné que les documents du cycle de vie sont encore à l'état d'ébauche, les gestionnaires de projet ont indiqué que certains éléments pouvaient être négociés et qu'on n'exécutait pas tous les éléments dans le cadre de tous les projets. Les exigences de la plupart des systèmes examinés étaient documentées. Tous les systèmes comportaient une description des essais de fonctionnalité, des critères d'assurance de la qualité et des essais d'acceptation. Même si le Guide des pratiques exemplaires du centre de solution contient un ensemble de modèles actuels, les vérificateurs n'ont pas relevé l'existence d'un ensemble d'outils de développement uniforme. Dans certains cas, on a utilisé un outil de mise à l'essai, dans d'autres cas, on ne mentionne aucun outil de ce genre. Par conséquent, d'après le corpus de documents professionnels sur les normes établies dans le domaine de la TI, on constate que le Ministère est conscient des processus requis pour concevoir des applications, mais que les pratiques sont mises en œuvre de façon réactive et incohérente.

De manière générale, dans les régions, les programmes font directement appel aux services de fournisseurs. Les propriétaires fonctionnels se fient aux normes des fournisseurs de services externes lorsque ce sont eux qui offrent les solutions d'entreprise. Par conséquent, les bureaux régionaux n'ont pas été en mesure de mettre en œuvre les normes ministérielles relatives au développement. Les processus de développement mis en œuvre en région varient donc considérablement. Une seule région a adopté un processus officiel qu'elle a intégré dans un ensemble d'outils. Les bureaux régionaux ont indiqué qu'ils n'avaient pas accès au cadre ou aux outils de développement de la DSGI, ou qu'ils ne savaient pas que ces outils étaient à leur disposition.

Recommandation 5

Il est recommandé que le sous-ministre adjoint de la Direction générale des services de gestion officialise le cycle de vie du développement des systèmes ministériel.

Réponse de la direction

La direction souscrit à la recommandation.

Plusieurs documents liés au cycle de vie du développement des systèmes existent déjà à l'intérieur de la Direction des services de gestion de l'information. Ces documents existants seront utilisés pour construire un cycle de vie du développement des systèmes ministériel officialisé.

3.2 Homologation

Critère de vérification : De nouveaux systèmes et changements doivent être homologués avant la mise en œuvre, y compris des mises à l'essai convenables dans un environnement dédié, accompagné de données d'essais pertinentes, de l'identification d'instructions de déploiement et de migration, de la gestion du lancement, d'une promotion réelle de la production et d'un examen après la mise en œuvre.

L'homologation et les environnements d'essai sont normalisés au sein de la DSGI. Le processus comporte plusieurs niveaux d'essai. L'équipe responsable de l'assurance de la qualité technique gère la progression des actifs liés aux applications, de l'étape du développement à l'environnement d'essai, puis à l'environnement de production. L'équipe technique gère aussi la configuration des serveurs. Une fois les essais fonctionnels terminés, les applications sont transférées à l'environnement de mise à l'essai d'acceptation du client. L'étape suivante du processus de développement consiste à transférer l'application à l'environnement de mise à l'essai de préparation d'acceptation dans le but d'analyser la mise en production. La dernière étape consiste à lancer l'application. C'est à ce moment que l'équipe de développement valide l'installation en effectuant une série d'essais rapides. Les problèmes soulevés, pendant ou après la mise en production, sont consignés dans le système de suivi des défaillances. Le processus d'homologation des applications élaboré pour Lotus Notes n'est pas aussi rigoureux, car la nature du travail n'est pas aussi importante. L'approbation du client est requise à chaque étape.

La procédure d'homologation varie dans les bureaux régionaux. Dans certains cas, il y a un mécanisme comportant des points de référence correspondant aux points de contrôle des critères d'homologation et aux produits finaux obligatoires. De manière générale, aucun outil d'essai automatisé n'a été mis en œuvre; les plans d'essais et les analyses ne sont pas officiellement consignés dans des modèles. Les clients ont souvent indiqué que le fournisseur exécutait la mise à l'essai des applications sans avoir recours à un modèle précis aux exigences d'information pour s'assurer que les clients contrôlaient ou élaboraient des modèles à des fins d'essais fonctionnels. Le processus d'assurance de la qualité consiste à appliquer des contrôles sommaires afin de s'assurer que l'application fonctionne, mais ne comprend pas un ensemble de procédures d'essai fonctionnel correspondant aux besoins fonctionnels.

Le processus adopté dépend du projet et du degré de contrôle accordé au client. Dans un cas, même si aucune étape ou méthode formelle n'avait été utilisée, le processus régional de gestion du changement a servi à orienter la production de produits d'applications convenables. Dans certains cas, le personnel du client a mis le produit et la documentation à l'essai et a documenté avec la participation du personnel des SGI. Les vérificateurs ont observé une seule instance où l'environnement de développement et l'environnement de production correspondaient à deux entités distinctes. Cette situation est survenue parce que le fournisseur a procédé au développement et aux essais à l'extérieur des locaux. Une seule région a indiqué avoir un outil intégré pour gérer le processus d'homologation ainsi que le développement et la mise en production. Lorsqu'on faisait appel aux services d'un fournisseur, ce dernier avait une approbation régionale pour avoir un accès direct à l'environnement de mise en production de Santé Canada.

Dans l'ensemble, les procédures d'homologation et les environnements d'essais sont normalisés à l'administration centrale, tandis qu'on a observé un contrôle interne moins rigoureux dans les bureaux régionaux. Dans les régions, on n'utilise pas systématiquement des approches normalisées. Les fournisseurs ne produisaient pas toujours des documents uniformes et les environnements d'essais ne font pas toujours la distinction entre le développement et la production. À l'avenir, la DSGI devra définir une stratégie visant à renforcer les critères d'homologation qui relèvent de son autorité puisque certaines étapes du processus d'homologation sont maintenant gérées par l'Agence des Services partagés Canada.

3.3 Gestion de la transition

Critère de vérification : Le processus de développement exige la planification de transition impliquant le partage de connaissances avec les utilisateurs et la technologie de l'information,  la prestation de formation pour assurer l'utilisation et le fonctionnement convenables des applications et de l'infrastructure et l'approbation officielle du récipiendaire organisationnel.

Le processus de transition qui mène au lancement de la production comprend les documents suivants : un calendrier de mise en œuvre, un guide de l'utilisateur, des notes de diffusion, des documents relatifs au soutien technique et des documents de soutien à la production. La valeur des produits livrés à cette étape est attribuée au fait qu'ils facilitent le transfert des connaissances et des compétences permettant au personnel des opérations et du soutien technique de soutenir efficacement le produit.

Parmi les mêmes projets de développement d'applications examinés, les vérificateurs ont relevé peu de procédures opérationnelles ou de conversion permettant la préparation des systèmes en vue d'un déploiement. Dans le cas d'une application déployée à l'échelle nationale, ils ont pu observer des exemples explicites d'exigences du système concernant la conversion des données. Les exigences d'information de projet ne comportaient toutefois aucun document sur les stratégies, les étapes et les procédures facilitant la conversion des données. L'absence de ces exigences d'information prouve que les organisations ne respectent pas systématiquement les modèles et les normes. En outre, il était impossible de déterminer la fin de l'étape de transition (autre que le changement consigné dans l'outil de production de rapports) dans certaines applications qui ont fait l'objet de vérifications. Même si cela ne fait pas partie des processus normalisés, les exercices sur les leçons apprises sont régulièrement utilisés et cela a permis de modifier les modèles de conception et d'établir des contrôles plus rigoureux.

La gestion de la transition à l'échelle régionale est surtout exécutée selon des processus non officiels, à l'exception d'une région qui utilise systématiquement un ensemble d'outils intégrés tout au long du cycle de vie du processus de développement des applications. Dans les autres régions, la migration de l'application ne respecte pas un processus de gestion défini. La migration des applications et des modèles de données est souvent exécutée dans l'environnement de développement ou de production sans être appuyée par des outils facilitant la migration ni par des procédures normalisées. Dans certains cas, le processus de gestion du changement entraine le contrôle des services de gestion de l'information sur l'environnement. Par exemple, le processus de gestion du changement exige que les hauts fonctionnaires de la TI se réunissent une fois par semaine afin de discuter de la façon dont les changements se répercuteront sur leurs infrastructures et de dresser des plans de substitution en cas de défaillance. Les examens post-mise en œuvre dans l'étape du cycle de vie du développement des systèmes sont décrits dans la méthode de développement. Chaque analyse permet de consigner les leçons apprises dans un dépôt.

L'analyse des applications régionales a permis de constater des éléments de mise en œuvre (guides de l'utilisateur et calendrier de mise en œuvre) intégrés aux produits livrables des vendeurs. Cet aspect positif a toutefois été atténué par un manque de preuves garantissant le transfert des connaissances concernant les éléments de soutien des applications aux services de gestion de l'information régionaux sous forme de manuels d'exploitation ou de spécifications de systèmes documentées. Dans un cas, les services de gestion de l'information ou les propriétaires fonctionnels ne connaissaient pas l'auteur de l'application. Dans certains cas, le fournisseur avait un accès direct à l'environnement d'essai et de production pour mettre en œuvre l'application ainsi que les corrections et les mises à jour.

3.4 Maintenance des applications et gestion du changement

Critère de vérification : Tous les changements et la maintenance liés à l'infrastructure et aux applications au sein de l'environnement de production doivent être officiellement enregistrés, évalués et autorisés avant la mise en œuvre et examinés par rapport aux résultats prévus après la mise en œuvre.

Peu de temps après la diffusion d'une application, la maintenance devient la responsabilité du groupe de maintenance. Elle va au-delà de la correction des défauts et devrait considérer le développement évolutionnaire ainsi que les coûts globaux du cycle de vie. Un plan fondamental de la maintenance devrait tenir compte de la façon dont les utilisateurs vont demander des modifications ou signaler des problèmes. La gestion du changement à la DSGI repose sur le processus de demande de développement d'élaboration d'applications.  L'étape de transition d'un projet envoyé à la mise en production dure habituellement entre un et quatre mois. L'équipe de conception exécute les activités de maintien (des corrections de bogues et non des améliorations). Après cette période de transition, le projet devient une application. C'est au tour de l'équipe de soutien à la production d'exécuter les activités de maintien. Cette équipe gère les demandes de changement par l'intermédiaire de l'Équipe accès aux marchés. Les demandes de développement d'applications ne concernent pas les améliorations, sauf si un programme en fait la demande à la suite d'un changement imposé par une loi ou un règlement.

Le processus de demande de l'élaboration d'applications est aussi considéré comme une fonction de soutien à la maintenance des applications, car il appuie les petites modifications. L'Équipe accès aux marchés a récemment fait l'objet d'une restructuration. Ses processus et ses procédures ont été officialisés. Les unités de conception et de maintenance travaillent à élaborer un processus officiel de gestion de la mise en œuvre, mais elles n'ont pas encore défini le concept de mise en œuvre « de maintien ». L'administration centrale prévoit lancer la mise en œuvre de maintien entre la mi-mars et la mi-septembre.

Dans les régions, les vérificateurs ont constaté qu'un processus ponctuel était respecté afin de gérer les changements pendant l'étape de mise en œuvre. Ils ont relevé de nombreux exemples de différents processus. Par exemple, dans une région, la portée des éléments de gestion du changement ne visait que les composants et les paramètres des applications et ne touchait pas les procédures et les documents. Dans une autre région, ils ont remarqué que les changements apportés aux applications conçues par des fournisseurs traités comme des urgences. Les gestionnaires de programmes envoient une demande au fournisseur de services, qui effectue les modifications demandées et les essais sur sa propre plate-forme de développement. Le vendeur envoie ensuite l'application modifiée aux services de gestion de l'information accompagnée d'une mise à jour des instructions d'installation. Dans une autre région, les changements aux applications régionales n'étaient pas contrôlés en utilisant les processus de la DSGI et les fournisseurs de services continuent toujours à faire des modifications directement dans l'environnement de production de Santé Canada. Dans un cas, le bureau régional des SGI a refusé une demande de changement envoyée par le fournisseur qui avait initialement été refusée et a ensuite été approuvée par la haute direction. Or, cette demande a été acheminée à la haute direction, qui l'a approuvée. Comme cela est mentionné dans d'autres sections du rapport de vérification, une région utilisait le même ensemble d'outils intégrés pour gérer le processus de changement. Cet ensemble constitue le pôle central autour duquel tous les changements relatifs à la TI sont gérés, y compris le développement et la maintenance des applications.

Les activités de maintenance sont contrôlées et gérées par la DSGI.  Cependant, l'efficacité et l'efficience globales du processus sont affectées en raison d'une capacité limitée. Ceci a des répercussions sur les domaines de programme et donc, certains clients agissent par eux-mêmes.  Santé Canada tirerait avantage d'un plan de TI à plus long terme énonçant la façon dont le Ministère gérera les nouvelles priorités en matière d'applications conjointement avec les systèmes existants afin de fournir les meilleurs services de TI. (voir la recommandation 3).

C - Conclusion

Santé Canada dispose de pratiques pour développer des applications et les maintenir mais profitera de renforcer l'orientation stratégique, la gouvernance, la gestion des risques et les contrôles internes de ce processus.

Étant donné que Santé Canada a un mandat de réglementer, de fournir des services de santé et de développer une politique sur la santé, une architecture de la TI qui s'appuie sur ces fonctions communes à travers les directions générales aidera le Ministère à identifier les applications dupliquées, réutilisables et partageables. La Direction des services de gestion de l'information travaille en vue de développer des modèles de référence organisationnels qui s'aligneront avec les principaux secteurs d'activités du Ministère. Cette direction fournira également au Ministère une nomenclature à travers les secteurs d'activités et une plateforme d'objectifs à partir de laquelle le Ministère sera en mesure de choisir les investissements en matière de TI.

Un recours accru aux pratiques de gouvernance et de gestion des projets établies dans le Processus de planification des investissements entraînera la prestation d'une surveillance accrue sur les projets de TI ainsi qu'une discipline accrue de la part de la Direction des services de gestion de l'information et des directions générales clientes en ce qui a trait aux exigences organisationnelles, aux évaluations des risques, aux analyses des options et aux approbations par l'entremise du processus d'approbation en fonction des points de contrôle. Les accords de niveau de services en matière de maintenance pour les nouvelles applications ainsi que pour les applications existantes fourniront une assurance aux directions générales quant à la continuité des activités et la Direction des services de gestion de l'information développera des indicateurs de rendement pour la maintenance.

Le fait que le personnel régional relève maintenant directement du dirigeant principal de l'information devrait renforcer les pratiques et offrir plus de contrôle interne et d'uniformité dans la prestation du service de développement et de maintenance des applications. De plus, le personnel régional viendra compléter le personnel de l'administration générale du point de vue de la capacité. Les deux groupes seront aussi en mesure de fusionner leurs pratiques exemplaires.

En établissant la méthodologie du cycle de vie du développement des systèmes du Ministère avec des contrôles mis à jour et une orientation, l'approche d'entreprise sera renforcée.

Bien que la Direction des services de gestion de l'information réduit activement le nombre d'applications au sein du Ministère, elle devra élargir cette initiative en vue de formuler un plan en matière de TI axé sur les risque à plus long terme énonçant comment le Ministère gérera les nouvelles priorités en matière d'applications conjointement avec le maintien des systèmes existants afin d'offrir les meilleurs services de TI.

Annexe A - Champs d'enquête et critères de vérification

Vérification des services à la clientèle de la TI - Processus relatif au développement et à la maintenance des applications Critères
Titre du critère Critère de vérification
Gouvernance et structure de prestation des services
Un nombre suffisant de mécanismes de surveillance existe pour s'assurer que les contrôles entourant le développement et la maintenance des applications de la TI correspondent adéquatement aux objectifs, que les rôles et les responsabilités illustrent un niveau approprié de répartition des tâches et que des mécanismes de surveillance sont en place pour atténuer les risques opérationnels.

1.1 Orientation stratégique

Le Ministère a défini une stratégie en matière d'architecture d'entreprise pour le développement d'applications qui est alignée avec les priorités du Ministère.
1.2 Surveillance de la direction Une surveillance convenable a été établie pour assurer que les applications des TI sont développées et maintenues conformément aux priorités organisationnelles.

1.3 Rôles et responsabilités

Les responsabilités et la responsabilisation relatives au développement et à la maintenance des applications de TI ont été clairement définies, documentées et comprises.
1.4 Suivi et rapport de la direction La direction a mis en place une surveillance propre au développement et à la maintenance des applications de TI pour rendre compte de l'état des objectifs fixés, des objectifs de rendement, de la prestation des solutions et de la satisfaction des clients.
Solutions organisationnelles en matière de TI et analyse des besoins
Santé Canada élabore un portefeuille de solutions organisationnelles en matière de TI basé sur une compréhension de l'environnement opérationnel du client, la détermination de la demande actuelle et future et une analyse du coût et du risque du développement et de la maintenance de la solution.
2.1 Évaluation des exigences opérationnelles Les exigences opérationnelles doivent être identifiées, priorisées et maintenues en couvrant la portée complète de tous les besoins organisationnels auxquels on doit répondre.
2.2 Évaluation du risque Les risques associés aux exigences opérationnelles et à la conception des solutions doivent être identifiés, documentés et analysés.
2.3 Faisabilité des solutions Des études sont effectuées pour examiner la faisabilité des solutions.
2.4 Approbation des commanditaires Le commanditaire organisationnel approuve les exigences opérationnelles et les rapports d'étude sur la faisabilité à des étapes principales prédéterminées.
Processus de développement et de maintenance des solutions organisationnelles de TI
Le processus de développement et de maintenance a été conçu afin de répondre au mieux aux besoins des utilisateurs et des priorités opérationnelles au sein de l'enveloppe financière.
3.1 Développement d'applications Le développement et la maintenance des applications sont effectués de manière à mieux répondre aux besoins des programmes et aux priorités du Ministère. Ces étapes respectent le processus d'élaboration, d'homologation, de gestion de la transition et de la maintenance des applications ou de la gestion du changement.
3.2 Homologation De nouveaux systèmes et changements doivent être homologués avant la mise en œuvre, y compris des mises à l'essai convenables dans un environnement dédié, accompagné de données d'essais pertinentes, de l'identification d'instructions de déploiement et de migration, de la gestion du lancement, d'une promotion réelle de la production et d'un examen après la mise en œuvre.
3.3 Gestion de la transition Le processus de développement exige la planification de transition impliquant le partage de connaissances avec les utilisateurs et la technologie de l'information,  la prestation de formation pour assurer l'utilisation et le fonctionnement convenables des applications et de l'infrastructure et l'approbation officielle du récipiendaire organisationnel.
3.4 Maintenance des applications et gestion du changement Tous les changement et la maintenance liés à l'infrastructure et aux applications au sein de l'environnement de production doivent être officiellement enregistrés, évalués et autorisés avant la mise en œuvre et examinés par rapport aux résultats prévus après la mise en œuvre.

Annexe B - Fiche d'évaluation

Les cotes et les explications qui les appuient résument l'état actuel de chaque critère de vérification.

Rapport de vérification définitif Services à la clientèle de la TI - Processus relatif au développement et à la maintenance des applications

Critère

Cote Conclusion Recommandation
Gouvernance et structure de prestation des services
Orientation stratégique AMoR La Direction des services de gestion de l'information (DSGI) doit établir une architecture d'entreprise fondée sur un processus organisationnel fonctionnel afin de fixer les meilleurs investissements en matière de le TI. 1
Surveillance de la direction AMoR La DGSI tirerait avantage d'utiliser le Cadre de gouvernance de la planification des investissements pour le développement de toutes les applications. 2
Rôles et responsabilités AMoR Les rôles sont bien définis au sein de la DGSI mais il existe un besoin d'établir une meilleure communication avec le personnel régional. Une nouvelle relation hiérarchique pour le personnel régional assurera que les normes de développement des applications sont respectées. Les accords de niveau de services permettront de clarifier les rôles et les responsabilités. 3
Suivi et rapport de la direction S La gestion du rendement pour le développement et la maintenance des applications est liée au Bureau d'exécution des projets et l'outil de présentation de renseignements concernant les projets.

La DSGI devrait s'appuyer sur le Processus de planification des investissements pour la surveillance et la présentation de renseignements.
2
Solutions organisationnelles en matière de TI/Cycle de vie du développement des systèmes
Évaluation des exigences opérationnelles
Évaluation des exigences opérationnelles AMoR

La DSGI a des éléments importants en place qui représentent un processus de gestion des besoins. Cependant, celui-ci tirera avantage de la mise à jour des documents de contrôle et d'orientation.

4
Régions
AMoR
Les processus régionaux diffèrent dans chaque région - certains d'entre eux sont très forts. 4
Évaluation du risque AMoR Les risques sont évalués au sein de la DSGI et des régions. Cependant, une approche globale est requise en impliquant l'administration centrale et les régions dans une vision architecturale unique. 4
Régions
AMoR
Il existait une rigueur plus approfondie au sein des processus de la DSGI que dans les régions. 4
Faisabilité des solutions AMiR

L'analyse de options et la faisabilité des solutions fait partie de la grille des jalons qui est promue par le Bureau d'exécution des projets. La recherche d'options faisait partie des systèmes dans l'échantillon de la vérification.

4
Régions
AMoR
Le manque des processus régionaux communs signifie que l'analyse des options n'est pas achevée de manière normalisée, ou pas du tout. 4
Approbation des commanditaires AMiR Les approbations sont normalement obtenues pour les projets de la DSGI dans le cadre du cycle de vie du développement des systèmes (grille des jalons). Une formalité plus accrue est nécessaire. 4
Régions
AMoR

Les approbations sont parfois présumées dans les régions car le commanditaire a souvent le contrôle de l'effort de développement.

4
Processus de développement et de maintenance
Développement d'applications AMoR

L'administration centrale a des éléments importants en place qui représentent un processus de gestion du développement. Le cycle de vie du développement est en forme d'ébauche et périmé.

5
Régions
AIR
Les processus régionaux diffèrent dans chaque région- certains d'entre eux sont forts, cependant, aucun d'entre eux ne se rapporte à ce que l'administration générale utilise actuellement. 5
Homologation S

Les environnements d'homologation et de mises à l'essai sont normalisés au sein de l'administration générale.  Certaines parties de l'homologation sont sous le contrôle de l'Agence des Services partagés Canada.

5
Régions
AIR

Il existait moins de contrôle dans les régions - on n'utilise pas toujours une approche normalisée et les fournisseurs ne produisent pas toujours de la documentation normalisée et les environnements de mises à l'essai n'étaient pas toujours séparés du développement et de la production.

5
Gestion de la transition S

Le contrôle sur les changements était relativement fort au sein de l'administration générale.

5
Régions
AIR

Il existe moins de contrôle dans les régions - en raison du fait qu'ils n'utilisent pas une approche normalisée et des conflits dans leurs relations avec leurs chefs des directions générales.  Une lacune existe dans les régions car les fournisseurs ont souvent un accès direct aux environnements de production.

5
Maintenance                    d'applications et gestion du changement S

Les activités de maintenance sont contrôlées et gérées au sein de l'administration générale. L'efficacité du processus est affectée par une préoccupation au sujet de la capacité, ce qui a un impact sur les réactions des clients.

3
Régions
AIR

Les changements régionaux peuvent être affectés par le degré auquel les clients comprennent leurs exigences (voir la gestion des exigences) et auquel les clients se sentent en mesure d'agir par eux-mêmes.

3

Légende :

S
- Satisfaisant
AMiR
- Améliorations mineures requises
AMoR
- Améliorations modérées requises
AR
- Améliorations requises
I
- Insatisfaisant
Inc
- Inconnu

Annexe C - Cadre de livraison des applications

Le tableau ci-dessous présente le cadre adopté par Santé Canada pour appuyer le développement et la maintenance des applications logicielles. La portée de la vérification était axée sur les processus associés au développement et à la maintenance des applications (section non-ombragée) et ne concernait pas le processus de planification permettant de sélectionner les projets (section ombragée).

Application delivery framework

Détails de la page

Date de modification :