Table des matières
Sommaire
Introduction
La Sécurité maritime a pour mandat de protéger la vie, la santé, les biens et le milieu marin dans le contexte d'un système de transport maritime efficace, durable et digne de confiance du public. Actuellement, la direction générale connaît d'importants changements : la fusion de la Sûreté maritime dans le but de créer la Direction générale de la sécurité et de la sûreté maritimes. Par ailleurs, l'unité de TI de la Sécurité maritime relèvera dorénavant de la Direction générale des services de gestion de la technologie et de l'information (DGSGTI), qui relève, quant à elle, des Services généraux.
Le projet d'architecture de base de la Sécurité maritime (ABSM) a été retenu pour la présente vérification. Ce projet a pour objectif d'intégrer les principales applications de la Sécurité maritime dans une seule infrastructure et de consolider les données afin d'en améliorer l'intégrité, la durabilité, l'uniformité et la transparence. Pour ce faire, il a fallu intégrer les systèmes de rapports d'inspection maritime, les systèmes d'emploi du temps et les systèmes de certification au sein d'une seule infrastructure. Toutefois, en raison de divers facteurs, dont des changements apportés aux règlements et des exigences en matière de sécurité des données, bon nombre des produits à livrer dans le cadre du projet ABSM ont subi des modifications considérables et n'ont donc pas été livrés selon les délais fixés.
Objectif et portée de la vérification
L'objectif global de la vérification était d'évaluer le caractère adéquat et l'efficacité des contrôles en place dans le but d'assurer la réalisation du projet ABSM . Par ailleurs, la vérification devait cerner les leçons tirées et les pratiques exemplaires en ce qui concerne l'élaboration d'applications de TI visant à permettre à la Sécurité maritime d'effectuer des rajustements en temps réel, lorsque cela est possible, dans les autres projets de TI en cours d'élaboration.
Conclusion
Dans le cadre de la vérification, on a conclu que le cadre de contrôle et les pratiques rattachées au projet ABSM doivent être grandement améliorés afin que le projet soit réalisé. Le projet n'est pas suffisamment surveillé, les processus normalisés de gestion de projet n'ont pas été suivis uniformément et aucun plan exhaustif permettant la réalisation du projet n'existe. Il convient de noter que l'équipe de la vérification a obtenu pendant la vérification des éléments de preuve qui démontraient que des travaux sont effectués par les Services de gestion de la technologie et de l'information (DGSGTI) ainsi que par la Sécurité maritime, qui relèvent du Ministère, pour améliorer les politiques, les procédures et les pratiques liées à la gouvernance et à la gestion des projets de TI au sein du Ministère.
Énoncé d'assurance/de fiabilité
Selon notre jugement professionnel, la vérification a été effectuée conformément aux Normes relatives à la vérification interne au gouvernement du Canada. Des procédures satisfaisantes ont été utilisées pour la vérification, et un nombre suffisant d'éléments de preuve pertinents ont été réunis pour appuyer l'exactitude des opinions du présent rapport.
Signatures
Signé par
Dave Leach, vérificateur interne autorisé, directeur, Services de vérification et de conseils
28 septembre 2012
Date
Signé par
Laura Ruzzier, dirigeante principale de la vérification
28 septembre 2012
Date
1. Introduction
1.1 Objet
La vérification du projet d'architecture de base de la Sécurité maritime (système en cours d'élaboration) est comprise dans le plan de vérification ministériel 2011-2012 en raison du degré élevé de risque inhérent lié aux initiatives d'élaboration de système. De plus, la vérification des contrôles du cycle de vie des projets de GI - TI de 2011 a cerné d'importantes faiblesses relatives au cadre de contrôle du Ministère en ce qui concerne la gestion des projets de GI - TI .
Le projet d'architecture de base de la Sécurité maritime (ABSM) II a été sélectionné en fonction de divers facteurs, dont le coût estimatif total du projet, l'importance du système pour le Ministère et le fait que ce système est élaboré par une équipe composée de ressources internes et contractuelles gérées par la Sécurité maritime (c. à d. le système n'est pas un produit commercial).
1.2 Contexte
1.2.1 Direction générale de la sécurité maritime
La Sécurité maritime, qui relève du Groupe de la sécurité et de la sûreté du Ministère, a pour mandat de protéger la vie, la santé, les biens et le milieu marin. La Sécurité maritime élabore et gère un programme national auquel prennent part environ 620 employés. Dans le cadre de son mandat, la Sécurité maritime :
-
élabore, gère et met en application des lois et des politiques nationales et internationales qui régissent la sécurité maritime et la protection du milieu marin;
-
fait la promotion de pratiques et de procédures sécuritaires;
-
élabore et tient à jour des règlements, des examens et des normes de formation pour la délivrance de brevets et de certificats (gens de mer), notamment les brevets de capacité;
-
traite les questions de santé et de sécurité au travail (navires);
-
tient un registre d'immatriculation des navires canadiens;
-
offre un programme interne de formation technique au groupe des inspecteurs du programme;
-
réalise des programmes afin de promouvoir la sécurité des petits bâtiments et des embarcations de plaisance;
-
mène des recherches dans le secteur du transport maritime (p. ex. équipement de sécurité);
-
gère le programme de protection des eaux navigables;
-
s'occupe des questions de pilotage.
L'Unité de gestion des applications de la Sécurité maritime, maintenant mise sur pied, est responsable de la conception, de l'élaboration, de la mise en œuvre et de la mise au point de toutes les applications logicielles de la Sécurité maritime ainsi que des services de gestion des applications (cela comprend la maintenance et le soutien). Actuellement, cette unité est composée de cinq employés à temps plein. Elle engage des programmeurs externes de technologie de l'information (TI) et des gestionnaires de projet sur une base contractuelle. Le directeur général de la Sécurité maritime est l'organisateur de tous les projets de TI de la Sécurité maritime, y compris celui de l' ABSM .
La Direction générale de la sécurité maritime est en pleine restructuration. Elle fusionne avec la Direction générale de la sûreté maritime Note 1 afin de former une seule direction générale responsable de la sécurité et de la sûreté maritimes. Cette restructuration a lieu au même moment qu'un bon nombre d'importants changements législatifs et réglementaires, tels que la délégation d'autres activités d'inspection des navires à des tiers. De plus, relativement à la décision récente du Ministère de consolider l'élaboration d'applications de GI - TI , l'Unité de gestion des applications de la Sécurité maritime et ses employés seront transférés à la Direction générale des services de gestion de la technologie et de l'information (DGSGTI), qui relève des Services généraux. On ne connaît pas encore la portée des répercussions de ces changements sur l'élaboration des projets de TI de nature maritime.
1.2.2 Projet d'architecture de base de la Sécurité maritime
Le projet ABSM a pour objectif d'intégrer les principales applications de la Sécurité maritime dans une seule infrastructure et de consolider les données dans le but d'en améliorer l'intégrité, la durabilité, l'uniformité et la transparence. L' ABSM concerne des applications nationales, telles que des systèmes de rapports d'inspection, des systèmes de rapports d'emploi du temps et des systèmes d'immatriculation de navires. La nouvelle infrastructure permettra également à la Sécurité maritime de répondre aux nouvelles exigences réglementaires de la Loi de 2001 sur la marine marchande du Canada (LMMC) et de redéfinir les applications incluses dans la portée du projet afin de respecter les normes techniques du Ministère.
Le plan de projet proposé, décrit dans le document d'approbation du projet (DAP) daté du 31 mars 2009, avait pour but d'intégrer sept applications de la Sécurité maritime. Le projet en question devait commencer en mars 2009 et se terminer en octobre 2012. Son coût estimatif total était de 3,6 millions de dollars (taxes non comprises). Selon l'approbation initiale, on était autorisé à dépenser 920 000 $ aux fins de la réalisation de la phase de planification du projet.
En mars 2010, une fois la phase de planification terminée, un DAP mis à jour a été présenté dans le but d'être approuvé. Ce deuxième DAP avait deux objectifs : obtenir l'approbation nécessaire pour entamer la phase d'élaboration du projet et élargir la portée du projet afin d'inclure quatre autres applications (la portée du projet ABSM concernerait donc, au total, 11 applications). Le nouveau coût estimatif total du projet ABSM était de 4,4 millions de dollars (taxes non comprises), et la nouvelle date de réalisation serait dans le mois d'octobre 2013.
Selon le plan de projet approuvé, au 31 mai 2012, environ 3,2 millions de dollars auraient été dépensés aux fins du projet et huit des onze applications auraient été terminées et mises en production. Les trois autres applications ( PCPB , NTARS et SRIN ) devaient être terminées en décembre 2012.
En date du 31 mai 2012, 3,6 millions de dollars avaient été dépensés aux fins du projet, plutôt que le montant prévu, soit 3,2 millions de dollars, et seule une application était terminée et avait été mise en production. Trois des onze applications avaient été annulées. Des sept autres applications, au moment de la vérification, trois sont presque terminées; cependant, elles ne seront pas mises en production avant le 31 mars 2013. Les quatre autres sont à diverses étapes d'élaboration, et il n'y a aucune date cible précise pour leur réalisation. Le tableau suivant dresse une liste des onze applications, de leur statut et du montant dépensé. Consulter l'annexe A pour lire une brève description de chaque application.
| Nom de l'application | Statut | Coût estimatif | Montant dépensé (données de mai 2012) Note 2 |
|---|---|---|---|
| * L'une des quatre applications ajoutées au projet ABSM en mai 2010. | |||
| Système automatisé d'immatriculation des navires (SAIN) | Terminée et mise en production | 340 000 $ | 397 673 $ |
| Système d'immatriculation des petits bâtiments commerciaux (SIPBC) | En cours d'élaboration | ||
| Système canadien de contrôle par l'État du port (SCCEP)* | En cours d'élaboration | 424 400 $ | 619 628 $ |
| Programme de conformité des petits bâtiments (PCPB) | En cours d'élaboration | 370 000 $ | 15 000 $ |
| Système d'identification et de sécurité des navires (BIASS)* | En cours d'élaboration | 85 000 $ | 92 224 $ |
| Système de délivrance des brevets de capacité (SDBC) | En cours d'élaboration (date estimative de réalisation mars 2013) | 300 000 $ | 1 108 700 $ |
| Compétence des conducteurs de petits bâtiments (CCPB)* | En cours d'élaboration (date estimative de réalisation mars 2013) | 265 000 $ | |
| Saisons de pêche (FISH7)* | En cours d'élaboration (date estimative de réalisation mars 2013) | 225 000 $ | |
| Système national de rapport d'emploi du temps et d'activités du personnel (NTARS) | Annulée | 75 000 $ | 14 622 $ |
| Système automatisé de certification et d'examen (ACES) | Annulée | 300 000 $ | 0 $ |
| Système de rapports d'inspection des navires (SRIN) | Annulée | 620 000 $ | 113 725 $ |
| Architecture ABSM | En cours d'élaboration | 952 900 $ | 1 200 603 $ |
| Fonds de prévoyance | 464 600 $ | ||
| TOTAL | 4 421 900 $ | 3 562 175 $ | |
Quant aux sept applications en cours d'élaboration, un certain nombre de facteurs ont causé des retards, p. ex. modification de règlements, exigences en matière de sûreté, réductions du financement des activités (qui est nécessaire une fois les applications terminées) et manque de membres du personnel de la Sécurité maritime pouvant élaborer et mettre à l'essai les applications.
La Sécurité maritime a fait savoir qu'il ne reste plus de fonds pour le projet ABSM , car les fonds non dépensés (environ 700 000 $, qui étaient auparavant 900 000 $, mais qui ont été réduits en raison des exigences en matière de réduction du déficit) ne sont plus offerts. La Sécurité maritime a signalé que cela avait été fait en prévision du transfert des produits à livrer et des fonds non dépensés du projet ABSM à d'autres projets de GI - TI de la Direction générale de la sécurité maritime. Les autres projets sont le SCSM/BISM et le SDDPM . Toutefois, le transfert des produits à livrer de l' ABSM à ces projets n'a pas encore été approuvé.
Le projet de SCSM/BISM a été entamé en 2009, et son objectif de départ était d'élaborer, d'enregistrer et de surveiller le processus d'accréditation des tiers en ce qui concerne l'inspection et la certification des bâtiments au nom du ministre des Transports. Ce projet vise également à simplifier l'établissement de rapports sur les données de la Sécurité maritime à l'aide de la consolidation des applications dans le cadre du projet ABSM . La Sécurité maritime est maintenant à l'étape de demander l'approbation en vue de changer considérablement l'orientation et la portée du projet. L'objet du projet de SCSM/BISM est maintenant d'appuyer la stratégie de production de recettes de la Sécurité maritime grâce à l'élaboration de l'application du Système d'affectation et de suivi de la Sécurité maritime. Cette application permettra la création d'une nouvelle structure de frais et assurera l'efficience en ce qui concerne le suivi et la perception des recettes. Trois des applications ( PCPB , NTARS et SRIN ) qui ont été annulées dans le cadre du projet ABSM devraient être terminées dans le cadre du projet de SCSM/BISM. Actuellement, on envisage une option en ce qui a trait à la réalisation du projet de SCSM/BISM : l'adoption du système de renseignements maritimes de sécurité et d'application de la loi (MISLE) de la Garde côtière américaine. Le projet SDDPM a été entamé en juin 2011. Il a pour objet de regrouper les processus d'examen et de délivrance de certifications dans un même système. Trois des applications du projet ABSM (FISH7, CCPB et SDBC) ont été transférées au projet de SDDPM en raison des exigences en matière de sécurité des données, bien que le transfert des produits à livrer n'ait pas été approuvé officiellement. Ni le projet de SCSM/BISM ni le projet de SDDPM n'a terminé ses produits à livrer selon la planification initiale.
1.3 Objectifs, portée et approche
L'objectif global de la vérification était d'évaluer le caractère adéquat et l'efficacité des contrôles en place dans le but d'assurer la réalisation du projet ABSM . Par ailleurs, la vérification devait cerner les leçons tirées et les pratiques exemplaires en ce qui concerne l'élaboration d'applications de TI visant à permettre à la Sécurité maritime d'effectuer des rajustements en temps réel, lorsque cela est possible, dans les autres projets de TI en cours d'élaboration.
La phase de planification de la vérification a servi à mieux comprendre le projet ABSM , à l'aide d'entrevues préliminaires et d'un examen documentaire, et à cerner les secteurs les plus à risque sur lesquels concentrer les contrôles de vérification. Il a été très difficile pour l'équipe de la vérification d'établir la planification et la portée de la vérification en raison du nombre d'applications rattachées au projet ABSM et du nombre de changements apportés aux applications dans le cadre du projet, dont la plupart n'ont pas été documentés. Dans la phase de planification, on a évalué quatre secteurs à risque généralement associés aux systèmes en cours d'élaboration : risques liés à la gouvernance, aux opérations, au projet et à la technologie/l'infrastructure.
Afin d'évaluer l'efficacité des contrôles mis en place aux fins du projet ABSM , l'équipe de la vérification a interrogé la Sécurité maritime (y compris les programmeurs et les utilisateurs des applications) et le personnel de la DGSGTI , a examiné la documentation sur le projet qui lui était accessible et a vérifié le statut de chaque application.
1.4 Critères
En fonction de l'objectif global de la vérification, voici ce que nous prévoyons constater :
-
Gouvernance – un cadre de contrôle de gestion est en place afin de garantir que les rôles, les responsabilités et les pouvoirs selon lesquels fonctionne le projet et selon lesquels sont prises toutes les décisions importantes concernant la portée et les objectifs sont bien définis.
-
Opérations – des processus ont été définis afin de réaliser les solutions opérationnelles cernées dans l'analyse de rentabilité du projet.
-
Projet – les pratiques de gestion du projet s'alignent sur les pratiques exemplaires de l'industrie et les politiques du Conseil du Trésor et du Ministère applicables.
-
Technologie – les plateformes technologiques choisies appuient la solution opérationnelle, et l'organisation a élaboré des plans qui permettent de s'adapter à la nouvelle technologie.
Une liste détaillée des critères se trouve à l'annexe B.
1.5 Structure du rapport
Les constatations du vérificateur sont présentées relativement à chacun des quatre secteurs à risque : risques liés à la gouvernance, aux opérations, au projet, à la technologie/l'infrastructure.
Les conclusions et les recommandations qui concernent les faiblesses et les lacunes des contrôles décrites dans la section des Constatations figurent dans les sections des Conclusions et des Recommandations. La section des Recommandations comprend également la Réponse et le plan d'action de la direction (RPAD) du Ministère. La direction réagit aux recommandations du vérificateur ainsi qu'aux engagements et aux délais en vue de remédier aux faiblesses ou lacunes relevées.
À l'annexe A, on fournit une description des applications de l' ABSM et, à l'annexe B, on décrit en détail les critères de la vérification.
2. Constatations – Risque lié à la gouvernance
2.1 Surveillance de la haute direction
La surveillance de la haute direction du projet ABSM est inadéquate.
Dans le plan approuvé de 2009 du projet ABSM , on affirmait qu'un comité directeur de l' ABSM serait mis sur pied dans le cadre de la gouvernance et de la surveillance du projet. Toutefois, ce comité n'a jamais été mis sur pied. En novembre 2011, le Comité directeur de la technologie de l'information (CDTI) de la Sécurité maritime a été mis sur pied afin d'assurer la surveillance de tous les projets de TI de la Sécurité maritime, y compris de l' ABSM . De mai 2009 à novembre 2011 (la période pendant laquelle il n'y avait aucun comité directeur), dans le cadre du projet, on a dépensé environ 2,9 millions de dollars, et des changements considérables ont été apportés au projet ABSM , tels que l'annulation de certaines des applications ainsi que le transfert d'applications à d'autres projets de TI de la Sécurité maritime. Bien que, dans les Principes directeurs, Investissement dans les activités de GI - TI de TC, il soit clairement énoncé que le comité directeur du projet doit approuver tout changement apporté à la portée, au calendrier et aux coûts, les changements apportés au projet ABSM n'étaient pas consignés ni approuvés officiellement.
Même si le CDTI n'a été mis sur pied que récemment et qu'il est trop tôt pour évaluer de façon définitive son efficacité, certains indices nous permettent de croire que le comité, dans sa forme actuelle, n'est peut être pas le mieux placé pour assurer une surveillance efficace de tous les projets de TI de la Sécurité maritime. Depuis sa création en novembre 2011, le CDTI a tenu trois réunions d'environ une heure. Étant donné que, à l'heure actuelle, cinq projets de TI relativement complexes sont en cours d'élaboration et que le Groupe de la sécurité maritime subit des changements organisationnels, il semble que la fréquence et la durée des réunions sont inadéquates. De plus, l'organisateur du projet ABSM , à qui revient la responsabilité de la réussite du projet, n'est pas un membre du CDTI .
Depuis la mise sur pied du CDTI , la haute direction de la Sécurité maritime reçoit plus d'information sur le statut de l' ABSM , y compris de l'information sur les risques liés au projet. Toutefois, beaucoup des renseignements sont communiqués par simple échange de correspondance. Par ailleurs, une partie de l'information communiquée à la haute direction ne parvient pas à refléter avec exactitude le statut du projet. Par exemple, dans un examen des rapports sur « l'état » (c. à d. rapport de situation) envoyés au CDTI , on observe que la portée du projet ABSM a été cotée « verte » même si trois des applications originales avaient été annulées. De plus, les renseignements contenus dans les rapports permettent difficilement à la haute direction d'évaluer le progrès du projet, car les rapports ne font pas allusion au progrès du projet en ce qui concerne les produits à livrer approuvés.
Pendant la vérification, la DGSGTI procédait au renforcement du modèle de gouvernance de GI - TI de TC à la suite d'une vérification interne récente des contrôles du cycle de vie des projets de GI - TI . Le renforcement du modèle de gouvernance de GI - TI définira le niveau de gouvernance nécessaire dans le cadre de projets de TI en fonction de critères définis, notamment le niveau de participation nécessaire de la part des comités directeurs, des groupes de travail consultatifs en matière d'opérations et des groupes de travail techniques.
La haute direction de la Sécurité maritime ne savait pas vraiment où en était le projet ABSM .
En mai 2012, un DAP révisé a été présenté à la DGSGTI à des fins d'examen dans le but d'obtenir une approbation pour fermer le projet ABSM et transférer certains des produits à livrer restants et des fonds non dépensés à d'autres projets d' ABSM . Bien que le DAP ait été examiné et approuvé par l'organisateur du projet avant d'être présenté à la DGSGTI , il énonçait à tort que huit des applications étaient terminées, alors que, en réalité, aucune n'était terminée ni mise en production.
2.2 Portée du projet/gestion des changements
Dans certains cas, les renseignements ainsi que les directives fournies dans le DAP sont insuffisants et font obstacle à l'évaluation du progrès et des résultats du projet.
L'équipe de la vérification a examiné les deux DAP approuvés pour le projet ABSM ainsi que cinq autres DAP (provisoires et approuvés) pour les projets d' ABSM , de SCSM/BISM et de SDDPM afin de mieux comprendre ces projets. L'examen du DAP approuvé de l' ABSM a révélé certains écarts et certaines lacunes. Par exemple :
-
Les produits à livrer ne correspondent pas aux détails en matière de coûts et de calendrier, ce qui rend très difficile, pour ne pas dire impossible, le suivi des projets et l'évaluation de l'état des projets.
-
Les avantages escomptés du projet ont été mentionnés dans diverses sections du DAP , mais la majorité d'entre eux n'étaient pas documentés de manière à permettre l'évaluation des résultats réels par rapport aux avantages escomptés.
-
La section sur l'analyse des options du DAP de l' ABSM était limitée. Par exemple, la Sécurité maritime signalait que des produits commerciaux ne constituaient pas une option viable dans le cadre du projet, mais aucune information n'a été fournie concernant la recherche qui a mené à cette conclusion.
Dans le cadre de l'examen des DAP , l'équipe de la vérification a également examiné le Guide pour le modèle de document d'approbation de projet (DAP) et a observé que, actuellement, il n'est pas nécessaire de faire le lien entre des produits à livrer ou des étapes importantes et des coûts ou un calendrier établis dans un DAP . Elle a également observé qu'il n'est pas exigé de consigner les recherches menées afin d'évaluer les options viables qui permettent de répondre aux exigences opérationnelles d'un projet. Quant aux avantages escomptés, le DAP a exigé qu'ils soient documentés de manière à permettre l'évaluation des avantages réalisés une fois le projet terminé en 2011 seulement, après la réalisation des DAP de l' ABSM .
D'importants changements qui ont été apportés au projet ABSM n'ont pas été approuvés en bonne et due forme dans le DAP mis à jour.
Selon le Manuel de politiques et de procédés financiers de TC , un changement apporté à un projet d'immobilisations déjà approuvé nécessite la préparation et la présentation d'un DAP révisé à des fins d'approbation. Il est obligatoire de présenter de nouveau un DAP lorsque « la qualité, les possibilités, la capacité ou la portée des étapes du projet approuvées par le Ministère ou le Conseil du Trésor sont augmentées ou diminuées, même si le niveau initial de financement reste le même. L'importance d'un changement concernant la portée d'un projet doit être déterminée par le parrain du projet qui doit prendre des mesures en conséquence ».
Le tableau ci dessous illustre les changements importants (y compris le transfert à d'autres projets de la Sécurité maritime et l'annulation d'applications) apportés à des produits à livrer approuvés de l' ABSM . D'importants changements ont été apportés à sept des onze applications. Cependant, aucun de ces changements n'a été approuvé de façon adéquate par des DAP mis à jour. La Sécurité maritime a bel et bien entamé la révision du DAP du SCSM/BISM au début de l'année 2012 afin de refléter le transfert de certains des produits à livrer du projet ABSM . Or, au moment de la fin de la présente vérification, en août 2012, le document n'avait pas encore été approuvé.
| APPLICATION | ABSM | SDDPM | SCSM/BISM |
|---|---|---|---|
| Système d'immatriculation des petits bâtiments commerciaux (SIPBC) |
|
||
| Système automatisé d'immatriculation des navires (SAIN) |
|
||
| Système canadien de contrôle par l'État du port (SCCEP) |
|
||
| Système national de rapport d'emploi du temps et d'activités du personnel (NTARS) |
|
|
|
| Système de délivrance des brevets de capacité (SDBC) |
|
|
|
| Système automatisé de certification et d'examen (ACES) |
|
|
|
| Système de rapports d'inspection des navires (SRIN) |
|
|
|
| Programme de conformité des petits bâtiments (PCPB) |
|
|
|
| Système d'identification et de sécurité des navires (BIASS) |
|
||
| Compétence des conducteurs de petits bâtiments (CCPB) |
|
|
|
| FISH7 |
|
|
|
| Légende | |
|---|---|
|
|
Terminée et mise en production |
|
|
En cours d'élaboration |
|
|
Annulée dans le cadre de l' ABSM , planification d'une élaboration future. |
|
|
En attente d'une approbation, l'application sera élaborée dans le cadre d'un autre projet. |
|
|
L'application a été transférée à un nouveau projet. |
Il convient de noter que, en novembre 2011, la vérification des contrôles du cycle de vie des projets de GI -TI a révélé que le processus d'approbation des projets de TI était compliqué. Par conséquent, le Ministère a choisi de mettre à jour les politiques et les procédures d'approbation des projets de TI au même moment que la Sécurité maritime procédait à la révision du DAP du SCSM/BISM.
2.3 Réalisation des avantages d'un projet
Comme le projet ABSM n'est pas terminé, l'évaluation de la rentabilité et des avantages réalisés ne peut être effectuée. Toutefois, la vérification a permis d'examiner certains des processus mis en place en vue d'appuyer l'évaluation des avantages réalisés et du succès du projet ABSM .
Il n'existe pas de processus normalisé pour l'attribution des numéros de projet qui servent à effectuer le suivi et la gestion des biens de GI - TI .
Les numéros de projet sont essentiels au suivi du progrès des projets, à l'évaluation de l'ensemble des résultats du projet et à la gestion des biens. Les conseillers en gestion financière du Ministère qui soutiennent tous les groupes du Ministère (c. à d. les conseillers de Sécurité et sûreté, des Politiques, des Programmes et des Services généraux) sont responsables d'attribuer les numéros de projet aux projets d'immobilisations. Les politiques ministérielles existantes ne fournissent pas une orientation claire de la manière dont les numéros de projet doivent être attribués aux projets et sur ce qui constitue exactement un nouveau projet et non une portée élargie d'un projet existant. En conséquence, l'utilisation des numéros de projet est incohérente.
Dans le cadre de la vérification, on a observé qu'on avait proposé de réutiliser un numéro pour l'un des projets de la Sécurité maritime qui n'avait rien à voir avec le projet original. Par ailleurs, dans le cadre du projet original, les produits à livrer approuvés n'avaient toujours pas été livrés.
Cette pratique fait en sorte qu'il est très difficile d'effectuer un suivi des coûts et de déterminer à quel moment un projet est terminé, puis d'évaluer l'ensemble des avantages du projet.
Le suivi des projets de GI - TI n'exige pas que l'on vérifie que les produits à livrer du projet sont terminés et mis en production.
Bien que la DGSGTI dispose d'un processus d'examen et d'approbation bien établi qui permet de mettre les applications en production, elle n'utilise pas de façon habituelle cette information afin d'effectuer le suivi du statut d'un projet de TI, décrit dans les DAP , qu'elle examine. Lorsque l'équipe de la vérification a relevé des écarts entre le DAP de clôture du projet ABSM et l'information reçue pendant les entrevues au sujet du statut des huit applications, elle a rencontré la DGSGTI afin de clarifier le statut des applications. La DGSGTI a affirmé que la présentation d'un DAP pour la clôture d'un projet est inhabituelle. Elle a ajouté que, étant donné que le DAP avait été examiné et approuvé par l'organisateur du projet avant de lui être présenté, elle n'avait pas cru nécessaire d'entreprendre un examen approfondi afin de vérifier le statut de chaque application. Dès que l'écart lui a été mentionné, l'unité de la DGSGTI qui est responsable d'envoyer les applications à l'environnement de production de TC a vérifié le statut des applications. Par la suite, elle a confirmé qu'aucune des applications n'était terminée au moment de la présentation du DAP .
Le Bureau de gestion et évaluation de projets (BGÉP) de la DGSGTI est responsable de s'assurer que le portefeuille d'investissements en GI - TI du Ministère est géré efficacement tout au long du cycle de vie de l'investissement. Cela comprend également la collecte et la synthèse des rapports de suivi rédigés pour chaque projet de TI (actuellement plus de 40 projets). Les organisateurs des projets informent le BGÉP lorsque leur projet est terminé; cependant, il n'est pas habituel de vérifier cette information auprès de l'unité de la DGSGTI responsable d'intégrer les applications au réseau de TC .
3. Constatations – Risque lié aux opérations
3.1 Exigences en matière de sécurité
L'évaluation de la menace et des risques du projet n'a pas été effectuée pendant la phase de planification du projet.
Bien que le plan initial du projet ABSM mentionne le besoin d'effectuer une évaluation de la menace et des risques (EMR) au cours de la phase de planification du projet, l'EMR n'a été effectuée qu'après la phase de planification.
L'EMR a pour but de cerner les exigences/questions de sécurité du système de TI ayant trait au projet. Si les résultats de l'EMR indiquent que des travaux supplémentaires sont nécessaires afin de satisfaire aux exigences de sécurité, cela peut avoir des répercussions sur la portée, le calendrier ou les coûts du projet. Ainsi, l'EMR est habituellement effectuée pendant la phase de planification d'un projet (une fois les exigences opérationnelles établies).
L'EMR de l' ABSM s'est terminée en mars 2010, une fois la phase de planification de l' ABSM terminée. L'évaluateur a conclu que toute la base de données rattachée au projet aurait besoin d'être classifiée (protégé B Note 3) en raison des renseignements personnels qui sont suivis et maintenus par quatre des applications du projet ABSM . Le coût supplémentaire associé à cette exigence était d'environ 400 000 $. À la suite de l'EMR, la Sécurité maritime a déterminé qu'il serait mieux de transférer ces quatre applications à un autre projet de la Sécurité maritime ( SDDPM ), qui avait déjà prévu un environnement « protégé B ».
Même si le transfert de ces quatre applications à un autre projet était la bonne décision à prendre sur le plan opérationnel, la reconnaissance de ces exigences après que le DAP a été préparé et présenté à des fins d'approbation a causé des retards dans le projet ABSM . Par ailleurs, il est difficile de déterminer si cela a entraîné des coûts supplémentaires.
Selon un examen du Cadre de gestion des projets de GI - TI du Ministère, il n'existe aucune directive ni orientation en ce qui concerne l'élaboration d'une EMR ou le moment où elle devrait être effectuée.
3.2 Exigences opérationnelles
Les exigences opérationnelles pour le projet ABSM ont été gérées de façon non officielle.
Les exigences opérationnelles définissent ce qui doit être livré; le propriétaire de l'application en est responsable, et non le personnel technique. Des exigences opérationnelles qui sont mal définies augmentent le risque qu'une fonctionnalité nécessaire ne sera pas incorporée dans la conception du logiciel de l'application, faisant en sorte que l'application ne réponde pas aux besoins de l'organisation. Des exigences opérationnelles mal définies augmentent également le risque qu'une fonctionnalité inutile soit intégrée au logiciel, ce qui causerait des retards ou des dépassements de coût.
Le vérificateur a conclu que les exigences opérationnelles pour l'ensemble du projet ABSM n'étaient pas documentées et que le format et le contenu des exigences opérationnelles pour chaque application variaient grandement. Quelques applications étaient bel et bien assorties d'exigences opérationnelles détaillées qui étaient approuvées par le propriétaire de l'application. Toutefois, dans d'autres cas, les seules exigences opérationnelles documentées relativement à l'application existaient depuis dix ans et se rapportaient à l'élaboration originale de l'application. Certaines applications n'étaient assorties d'aucune exigence opérationnelle documentée.
Les lacunes en ce qui concerne la documentation des exigences opérationnelles ont également été notées dans la vérification des contrôles du cycle de vie des projets de GI - TI . En réponse aux recommandations formulées dans la vérification, la DGSGTI s'apprête à rendre obligatoires la documentation officielle et l'approbation des exigences opérationnelles pour tous les projets de TI .
4. Constatations – Risque lié au projet
4.1 Processus d'élaboration/d'acquisition
Les pratiques normalisées en matière de gestion et d'élaboration des projets de TI n'ont pas été respectées dans le cadre du projet ABSM .
De bonnes pratiques de gestion des projets et des documents à l'appui facilitent la surveillance des projets et permettent de réduire les risques et de garantir que les projets sont menés selon les délais, le budget et les avantages escomptés. En ce qui concerne le projet ABSM , le vérificateur a conclu ce qui suit :
-
les rapports sur les dépenses réelles par rapport aux estimations budgétaires n'ont pas été établis de manière régulière;
-
les pratiques en matière de gestion des risques étaient officieuses, et les registres de risques n'étaient pas mis à jour régulièrement;
-
les procédures de gestion des changements permettant d'évaluer et d'approuver les modifications de la portée de l' ABSM n'étaient pas en place;
-
des contractuels ont été utilisés pour différents projets de TI de la Sécurité maritime. Dans certains cas, l'énoncé des travaux du contrat n'indiquait pas clairement les projets de TI ni les produits à livrer sur lesquels l'employé contractuel allait travailler. Cela faisait en sorte qu'il était difficile d'effectuer le suivi du contrat en ce qui concerne les projets de TI .
Il convient de noter que l'on a remis à l'équipe de la vérification des éléments de preuve selon lesquels des améliorations ont récemment été apportées aux pratiques de gestion de projet dans le cadre du projet ABSM . Par exemple, des registres de risques ont été élaborés pour certaines applications. Un processus de gestion des changements et des éléments de preuve ont été fournis afin de démontrer que les changements au projet ABSM ont été apportés en respectant le processus.
L'un des éléments importants de la gestion de projet consiste à déterminer les principales étapes de la prise de décisions en ce qui concerne le financement. Selon les COBIT et le Conseil du Trésor, les pratiques exemplaires fournissent une « approche par étapes » selon laquelle la direction examine le progrès, les coûts et le calendrier à des moments précis et fixés en vue de déterminer si un projet devrait se poursuivre. Cette pratique exemplaire ne faisait pas partie du Cadre de gestion des projets de GI - TI de TC lorsqu'on a commencé l' ABSM et n'était pas en place au moment de sa réalisation. La DGSGTI procède maintenant à la mise en œuvre d'une « approche par étapes » pour tous les projets de GI - TI .
Le cycle de développement de logiciels (CDL) est le processus d'élaboration d'une application logicielle qui permet de répondre à des exigences opérationnelles précises. Il englobe de nombreuses choses : la pertinence de l'élaboration de l'application, la faisabilité du projet, le choix de la conception et de l'architecture de l'application, sa mise en œuvre ainsi que sa mise à l'essai, puis la livraison du produit final à l'utilisateur. L'adoption d'une méthodologie normalisée du CDL aide à utiliser les ressources de façon efficiente, à définir les rôles et responsabilités, à faciliter la communication d'information et à réduire les risques liés à l'élaboration d'applications logicielles.
Macroscope, un ensemble d'outils d'élaboration de système qui comprend la méthodologie relative au cycle de développement de logiciels, est la norme à TC depuis de nombreuses années. Macroscope est vaste et complexe et beaucoup trop compliqué pour bon nombre de petites et moyennes applications. La DGSGTI reconnaît que l'exigence selon laquelle il faut suivre cette norme a été mal communiquée au sein du Ministère et que l'on n'a pas encore effectué de suivi en ce qui concerne le respect de cette norme. Dans le cadre du plan d'action de la direction en réaction à la vérification des contrôles du cycle de vie des projets de GI - TI , la DGSGTI a récemment élaboré une directive relative au CDL qui mentionne la nécessité d'utiliser Macroscope, et elle est en train d'adapter les exigences de Macroscope afin de s'assurer qu'il est possible de le suivre dans le cadre de projets de différentes complexités.
5. Constatations – Risque lié à la technologie et à l'infrastructure
5.1 Répercussions sur la technologie et l'infrastructure
Le projet ABSM a connu des problèmes relatifs à l'architecture de la TI. Cependant, le Ministère procède actuellement à une amélioration des contrôles qui s'y rattachent afin de prévenir que de tels problèmes surviennent de nouveau.
Les travaux d'élaboration de l'architecture sous-jacente du projet ABSM ont commencé en 2009 et se sont terminés en août 2010, même si on n'avait pas approuvé le commencement des travaux d'élaboration avant juin 2010 (après l'approbation du DAP mis à jour). Ces travaux d'élaboration de l'architecture ont été effectués par des employés contractuels. D'août 2010 à janvier 2011, des travaux supplémentaires ont été effectués par le personnel de la TI de la Sécurité maritime afin que l'on puisse faire fond sur l'architecture créée par l'entrepreneur. Pendant cette période, le personnel de la TI de la Sécurité maritime a déterminé que l'architecture de l'entrepreneur était beaucoup trop complexe, fortement personnalisée et non conforme aux méthodologies de conception reconnues par le Ministère ou par l'industrie. Bien que l'architecture ait été considérée comme étant adéquate pour soutenir certaines des applications du projet ABSM , elle ne constituait pas une solution adéquate à long terme afin que toutes les principales applications de la Sécurité maritime puissent y être intégrées.
L'équipe de la vérification a tenté de savoir pourquoi les travaux d'élaboration ont été effectués avant l'autorisation et pourquoi l'architecture avait été créée de manière à ce qu'elle ne puisse pas soutenir l'objectif global du projet. Cependant, aucune réponse claire n'a suivi ces questions, car le gestionnaire qui était responsable du projet ABSM à cette époque et qui a supervisé les travaux d'élaboration a quitté le Ministère pour prendre sa retraite à l'été 2010. Par ailleurs, ce gestionnaire n'avait pas suffisamment documenté les décisions qu'il avait prises.
Depuis 2010, le Ministère a mis en œuvre d'autres contrôles qui permettront de prévenir que ce type de situation survienne de nouveau. Par exemple, les contrats de TI doivent maintenant être soumis à un examen et une justification supplémentaires avant d'être mis en place. Par ailleurs, la DGSGTI lancera sous peu un cadre de gouvernance de GI - TI révisé selon lequel il sera nécessaire de mettre sur pied un groupe de travail technique composé de membres de la DGSGTI , ainsi que des processus assurant le respect des exigences en matière de CDL et de gestion de projet.
Étant donné que l'architecture actuelle du projet ABSM est considérée comme étant inadéquate pour soutenir toutes les principales applications cernées, la Sécurité maritime cherche actuellement d'autres solutions à long terme dans le cadre du projet de SCSM/BISM. Comme on l'a déjà mentionné, l'une des options envisagées est le MISLE de la Garde côtière américaine. En plus de comprendre entièrement les exigences opérationnelles du Groupe de la sécurité maritime, il sera nécessaire d'effectuer une évaluation détaillée de la technologie utilisée par le MISLE afin de déterminer si cette option est la meilleure pour la Sécurité maritime. La DGSGTI s'est engagée à travailler avec la Sécurité maritime dans le cadre de cette évaluation.
6. Conclusions
La vérification a révélé que le cadre de contrôle du projet ABSM a besoin de beaucoup d'améliorations afin d'assurer la réalisation du projet. Le projet n'est pas suffisamment surveillé, les processus normalisés de gestion de projet n'ont pas été suivis uniformément et il n'existe aucun plan exhaustif permettant la réalisation du projet. Il convient de noter qu'au cours de la vérification, l'équipe de la vérification a obtenu des éléments de preuve qui démontraient que des travaux sont effectués par les Services de gestion de la technologie et de l'information (DGSGTI) ainsi que par la Sécurité maritime, qui relèvent du Ministère, pour améliorer les politiques, les procédures et les pratiques liées à la gouvernance et à la gestion des projets de TI au sein du Ministère.
7. Recommandations et Plan d'action de la direction
| Recommandation | Plan d'action détaillé de la direction | Date d'achèvement
(pour chaque mesure) |
Rapport direct du BPR pour chaque mesure précise |
|---|---|---|---|
|
Cote de la recommandation – Élevée Le SMA, Sécurité et sûreté, doit examiner tous les projets de TI en cours ou prévus en collaboration avec la Sécurité maritime et la Sûreté maritime dans le but d'évaluer l'harmonisation des projets avec les priorités et les besoins opérationnels de la nouvelle Direction générale de la sécurité et de la sûreté maritimes. L'examen doit tenir compte des changements en cours, des changements apportés aux règlements, de l'accès aux ressources (fonds et employés) et de l'initiative de consolidation des applications du Ministère. Il doit également mentionner les projets qui devraient se poursuivre et ceux qui devraient être mis de côté ou annulés. Les résultats de cet examen doivent être présentés au sous-ministre afin qu'il l'approuve. |
La Direction générale (DG) de la sécurité et de la sûreté maritimes élaborera un document d'établissement des priorités opérationnelles qui cerne les principaux projets de TI de la DG de la sécurité et de la sûreté maritimes et les exigences à court terme dont on doit tenir compte afin de répondre aux priorités opérationnelles urgentes. | mars 2013 | DG et dirigeants, Sécurité et sûreté maritimes |
| Une fois élaboré, le document d'établissement des priorités opérationnelles sera examiné de près par le Comité directeur de la TI de la Sécurité et sûreté maritimes et par le Comité exécutif de la Sécurité et sûreté maritimes. Ce document tiendra compte de la disponibilité des ressources humaines et financières. Une fois l'examen terminé, il sera présenté au SMA, Sécurité et sûreté, et au sous-ministre à des fins d'approbation. Le document servira à appuyer les demandes d'investissement en GI - TI de la DG de la sécurité et de la sûreté maritimes pour 2012-2013 et 2013-2014. | DG, Sécurité et sûreté maritimes, DG, Services de gestion de la technologie et de l'information et SMA, Sécurité et sûreté | ||
| Le SMA, Sécurité et sûreté, recevra tous les mois des mises à jour sur l'état de tous les projets de TI de la Sécurité maritime (y compris l' ABSM ) dans le cadre d'une rencontre bilatérale prévue entre le SMA, Sécurité et sûreté, et le DG, Sécurité et sûreté maritimes. | SMA, Sécurité et sûreté, et DG, Sécurité et sûreté maritimes | ||
| Le SMA, Sécurité et sûreté, recevra chaque trimestre de la part du DG, Sécurité et sûreté maritimes, et du DG, Services de gestion de la technologie et de l'information, des renseignements sur les projets de TI . Ces renseignements concerneront les mises à jour sur l'état, la situation financière, et les principaux produits à livrer (achevés et planifiés). | SMA, Sécurité et sûreté, DG, Sécurité et sûreté maritimes, et DG, Services de gestion de la technologie et de l'information | ||
| Sécurité et sûreté maritimes et la DGSGTI mettront sur pied une stratégie/un plan d'investissement de GI - TI pour la DG de la sécurité et de la sûreté maritimes pour 2014-2015 et 2015-2016. Ce plan s'intégrera à la stratégie/au plan d'investissement en GI - TI du Ministère. Ce document établira des liens avec les plans et les priorités opérationnels. | SMA, Sécurité et sûreté, DG, Sécurité et sûreté maritimes, et DG, Services de gestion de la technologie et de l'information | ||
| Le SMA, Sécurité et sûreté,et le DPI/DG, Services de gestion de la technologie et de l'information, feront le point deux fois par année sur la Stratégie de TI de la DG de la sécurité et de la sûreté maritimes et sur ses plans globaux de TI afin que le sous-ministre les approuve. Cette mise à jour portera sur l'état des projets et des priorités de TI , y compris les projets que l'on doit poursuivre, mettre de côté ou annuler, les exigences en matière de ressources et les principaux secteurs à risque. Elle comprendra également les résultats obtenus/escomptés. | SM, Sécurité et sûreté, DPI/DG, Services de gestion de la technologie et de l'information, et sous ministre | ||
|
Cote de la recommandation – Moyenne Si l'on détermine, en fonction de l'examen de tous les projets de TI de la Sécurité maritime et de la Sûreté maritime, que l' ABSM doit se poursuivre, le SMA, Sécurité et sûreté, doit élaborer un plan global qui permettra de terminer le projet ABSM . Ce plan doit clairement indiquer les produits à livrer ainsi que les coûts, les délais, le calendrier et les responsabilités qui s'y rattachent. Il doit également être approuvé en bonne et due forme. Il faut établir une structure par étapes afin que des examens officiels soient menés relativement au progrès du projet, à ses coûts et à son calendrier à des moments clés prédéfinis, pour qu'on puisse déterminer si un projet doit se poursuivre. |
Une fois le document d'établissement des priorités opérationnelles déposé, si l'on confirme que l' ABSM est une priorité, on élaborera des options pour permettre l'achèvement des produits de l' ABSM qui restent à livrer : SCCEP, eaux de ballast, système de suivi des fabricants de petits bâtiments et Système d'immatriculation des petits bâtiments commerciaux, selon les priorités opérationnelles. Les options comprendront les coûts et le calendrier qui s'y rattache afin que le Comité exécutif de la sécurité et de la sûreté maritimes et le Comité directeur de la TI de SSM puissent établir les priorités. Cette analyse établira des liens avec les priorités opérationnelles. | janvier 2013 | DG, Sécurité et sûreté maritimes, et Comité exécutif de SSM |
| Le SMA de Sécurité et sûreté recevra chaque trimestre de la part du DG de Sécurité et sûreté maritimes et du DG des Services de gestion de la technologie et de l'informatique des renseignements sur les projets de
TI
. Ces renseignements concerneront les mises à jour sur l'état, la situation financière, et les principaux produits à livrer (achevés et planifiés).
(Tel que mentionné plus haut dans la première recommandation) |
SMA, Sécurité et sûreté
DG, Sécurité et sûreté maritimes, et DG, Services de gestion de la technologie et de l'information |
||
| Le document d'approbation du projet ABSM sera mis à jour avec l'ajout de produits à livrer plus clairs, de structures par étapes et de coûts associés cernés, de délais, d'un calendrier et des responsabilités du Comité des investissements dans la GI - TI opérationnelle de TC ainsi que de la situation relativement à l'investissement pour le cycle 2013-2014/2014-2015. | DG, Sécurité et sûreté maritimes, DG, Services de gestion de la technologie et de l'information, et SMA, Sécurité et sûreté. | ||
|
Cote de la recommandation – Moyenne Le SMA, Sécurité et sûreté, doit renforcer la structure de gouvernance mise en place au sein de la DG de la sécurité et de la sûreté maritimes en ce qui concerne les projets de TI afin de s'assurer que l'on procède à une surveillance efficace des projets de TI du groupe. Cela concerne également la prise en considération du contenu et de la fréquence des réunions ainsi que de la représentation de tous les organes de gouvernance. Par ailleurs, la structure de gouvernance doit être alignée sur le modèle de gouvernance mis à jour de la DGSGTI pour les projets de TI . |
Amélioration du mandat du Comité directeur de TI de SSM afin d'y inclure des membres de la haute direction de la DGSGTI et des Finances et de renforcer les éléments globaux de la gouvernance, de la gestion des projets et de la surveillance de la gouvernance de la TI de SSM. | février 2013 | DG, Sécurité et sûreté maritimes, DG, Services de gestion de la technologie et de l'information, SMA, Sécurité et sûreté, et représentant des Finances, au besoin |
| Établissement d'un cadre qui permet d'appuyer et de créer des comités directeurs pour chaque projet, des groupes de travail techniques et des groupes de travail consultatifs en matière d'opérations, comme l'exige le Cadre de gestion des projets de GI - TI . | DG, Sécurité et sûreté maritimes, dirigeants de SSM et DG (ou délégués) des Services de gestion de la technologie et de l'information | ||
| Élaboration d'accords sur les niveaux de service afin de définir clairement les rôles, les responsabilités et les normes en matière de service et de consigner tous les détails sur le transfert de ressources de TI (ETP et ACF) de Sécurité et sûreté maritimes à la DGSGTI . | DG, Sécurité et sûreté maritimes, dirigeants de SSM et DG, Services de gestion de la technologie et de l'information | ||
|
Cote de la recommandation – Moyenne Le Cadre de gestion des projets de GI - TI du Ministère fait l'objet d'une mise à jour et d'un renforcement en réaction à des vérifications internes récentes des contrôles de projets de GI - TI et de l'approvisionnement en GI - TI . Le SMA, Services généraux, doit s'assurer que les lacunes cernées par la vérification seront également prises en considération dans le cadre des révisions du Cadre en cours d'élaboration, dont :
|
Le point sur le Cadre de gestion des projets de GI - TI doit comprendre :
|
septembre 2012 | DPI/DG, DGSGTI |
|
Renforcement du document d'approbation du projet (DAP) par la révision du Projet d'immobilisation de la GI - TI – Liste de vérification pour l'examen fonctionnel (SGDDI no 7120929) afin d'inclure une orientation fonctionnelle en matière de GI - TI améliorée et d'examiner les secteurs suivants :
|
DPI/DG, DGSGTI | ||
| S'assurer que le lien entre un projet d'immobilisations terminé et le produit final mis en production est clair en révisant le Rapport de clôture de projet de GI - TI (SGDDI no 6706314) afin qu'il inclue un tableau de référence des versions du système qui comprend les renvois du Conseil de contrôle des changements à toutes les versions produites pendant le cycle de vie du projet. | DPI/DG, DGSGTI |
Liste des annexes
REMARQUE : DES ANNEXES ONT ÉTÉ RETIRÉES ET SONT DISPONIBLES SUR DEMANDE
- Annexe A – Description des applications de l' ABSM
- Annexe B – Liste détaillée des critères de la vérification
- Annexe C – Échelle de notation des conclusions des rapports de vérification
- Annexe D – Échelle de notation des recommandations des rapports de vérification
Notes
Note 1 La Direction générale de la sûreté maritime est responsable des politiques et des affaires réglementaires en matière de sûreté maritime, des activités de la sûreté maritime et de l'autorité fonctionnelle en ce qui a trait aux activités régionales de sûreté maritime. (Retourner au paragraphe source note 1)
Note 2 Les détails relatifs au montant dépensé pour chaque application ont été fournis par la Sécurité maritime. Le Système financier ministériel a fait concorder le total des montants dépensés. (Retourner au paragraphe source note 2)
Note 3 Une divulgation non autorisée risquerait vraisemblablement de causer un préjudice grave à une personne, un organisme ou un gouvernement. Selon TC, les renseignements « protégé B » comprennent notamment l'évaluation de rendement et de références morales d'un individu, un casier judiciaire, un secret professionnel, un rapport médical et une évaluation des risques organisationnels. (Retourner au paragraphe source note 3)
Ce document peut être visualisé ou téléchargé :
- Système en cours d'élaboration : Vérification du projet d'architecture de base de la Sécurité maritime (Version PDF , 649 kb )
Pour consulter la version PDF (format de document portable), vous devez avoir un lecteur PDF sur votre ordinateur. Si vous n'en avez pas déjà un, il existe de nombreux lecteurs PDF que vous pouvez télécharger gratuitement ou acheter dans Internet :