Rapport de vérification interne des systèmes de TI en développement - Phase 2
Déclaration de l'Information préalable sur les expéditions commerciales - Échange de données informatisé pour le mode aérien

Octobre 2007

Table des matières

• Sommaire
• Introduction
  • Contexte
  • Objectifs et étendue
  • Critères de vérification
  • Stratégie et méthodes
  • Résultats de la phase 1
  • Objet
• Vue d'ensemble de la déclaration IPEC - EDI pour le mode aérien
• Constatations de la vérification
  • Élaboration d'une solution technique
  • Transformation des activités
  • Autorité, responsabilité et responsabilisation
  • Cadre de gestion des projets
  • Gestion des risques du projet
  • Évaluation de la sécurité
• Annexe A - Critères de vérification
• Annexe B - Liste des acronymes

Sommaire

La vérification des systèmes en développement de l’Agence de services frontaliers du Canada (ASFC) a été déterminée comme une priorité dans le Plan de vérification pluriannuel axé sur les risques de l’ASFC. Ce plan a été approuvé par le Comité de la vérification interne et de l’évaluation le 17 mars 2005.

Le principal objectif de la présente vérification était de donner l’assurance nécessaire à l’ASFC que ses pratiques et procédures intégrées de gestion des projets et d’élaboration des systèmes pour les systèmes opérationnels automatisés en développement respectent les politiques et les procédures internes qui ont été établies par l’Agence. Un autre objectif de cette vérification était de cerner les occasions d’améliorer les politiques et les procédures internes en vigueur de l’ASFC en ce qui a trait à la gestion de ses systèmes en développement.

La vérification s’est divisée en trois phases. La phase 1, sur laquelle il a été fait rapport en février 2007, renfermait une évaluation de la pertinence et de l’efficacité du cadre actuel de contrôle de gestion de l’ASFC pour les systèmes en développement. Les phases 2 et 3 fournissent une évaluation de la mesure dans laquelle deux projets choisis d’élaboration de systèmes appliquent avec efficacité et de la façon appropriée le cadre de contrôle. Le présent rapport renferme les constatations découlant de la phase 2 de la vérification, qui devait examiner le cadre de gestion utilisé lors de l’élaboration d’un certain projet de développement de systèmes, celui de la déclaration de l’Information préalable sur les expéditions commerciales (IPEC) - Échange de données informatisé (EDI) pour le mode aérien. La vérification a été effectuée par Interis Conseils, et le travail de vérification sur place a eu lieu entre juillet et octobre 2006.

La déclaration IPEC - EDI pour le mode aérien est une composante de l’initiative IPEC, qui est une initiative pluriannuelle de plusieurs millions de dollars lancée conformément au Plan d’action des douanes en 2000, avant la formation de l’ASFC en décembre 2003. L’IPEC fournit à l’ASFC des données sur les expéditions commerciales entrant au Canada avant l’arrivée de celles-ci. Ces données servent à repérer le fret commercial et les expéditions commerciales à risque élevé nécessitant un examen plus minutieux à l’arrivée. Une approche graduelle multimodale a présidé à l’élaboration de l’IPEC. L’IPEC est en activité dans le mode maritime depuis avril 2004 et elle l’est dans le mode aérien depuis décembre 2005 (par une mise en œuvre échelonnée jusqu’en juillet 2006). La mise en œuvre dans les autres modes, routier et ferroviaire, se poursuit grâce au projet Manifeste électronique.

L’objectif de la vérification dans la phase 2 était d’évaluer l’élaboration de la déclaration électronique de l’information préalable pour le mode aérien. Ce projet a été élaboré par la Direction générale de l’innovation, des sciences et de la technologie (DGIST) et était parrainé par la Direction générale de l’exécution de la loi, la Direction générale de l’admissibilité et la Direction générale des opérations.

Constatations de la vérification

D’après le travail de vérification effectué dans la phase 2, il peut être conclu que la déclaration IPEC - EDI pour le mode aérien a été élaborée conformément aux politiques, aux procédures et aux méthodes de l’ASFC en vigueur à l’époque et que la fonctionnalité de l’application est bien celle envisagée. Bon nombre des observations faites dans la phase 1 de la vérification ont été appuyées par le travail de vérification dans la phase 2. En outre, la vérification a permis de signaler que, depuis l’élaboration de la déclaration IPEC - EDI pour le mode aérien, en 2004 et 2005, beaucoup de nouveaux processus et de nouvelles pratiques de régie ont été élaborés et introduits pour des projets plus récents.

La vérification a permis de signaler un certain nombre de points forts dans le projet de déclaration IPEC - EDI pour le mode aérien, notamment l’utilisation d’une solide approche dans l’élaboration des systèmes qui comprenait les activités suivantes :

• Une évaluation de la faisabilité et de la viabilité de la solution.
• La définition des exigences des utilisateurs avec la participation des intervenants.
• Une mise à l’essai appropriée.
• La mise en œuvre de la déclaration IPEC - EDI pour le mode aérien a été bien gérée. Le milieu des transporteurs a été régulièrement informé des progrès et a reçu les renseignements et les instruments devant mettre les transporteurs à même de transmettre électroniquement leurs données.
• Une structure et des processus officiels ont été mis en place à l’appui des transporteurs externes.

Bien que de nombreuses constatations découlant de la vérification de la déclaration IPEC - EDI pour le mode aérien soient identiques à celles figurant dans le rapport de vérification sur la phase 1, des secteurs de contrôle additionnels ont été identifiés dans la phase 2 et ils pourraient être renforcés au niveau du projet, à savoir :

• Autorisation, responsabilité et responsabilisation -- Elles devraient être clairement définies dès le début d’un projet d’élaboration de systèmes, ce qui n’était pas le cas dans ce projet. L’engagement des parrains n’était pas bien compris, assuré et consigné au début du projet.
• Cadre de gestion des projets -- À ce chapitre, la phase 2 de la vérification a déterminé ce qui suit :
  • La planification et l’échéancier n’étaient pas suffisamment intégrés dans toutes les directions de la DGIST pour garantir que les interdépendances étaient clairement comprises et que les dates clés étaient planifiées de manière à respecter les dates prévues des versions et d’améliorer l’efficacité;
  • Le processus de gestion du changement n’avait pas été pleinement défini et communiqué aux parrains, y compris les attentes et les autorisations pour les approbations;
  • Le processus de gestion des problèmes n’était pas toujours en place pour systématiquement documenter, suivre et classer les problèmes d’élaboration en vue d’une solution efficace et efficiente.
• Évaluation de la sécurité -- Le rôle du Groupe de la sécurité des TI dans la DGIST et du Bureau de la sécurité de l’Agence (BSA) devrait être clarifié en ce qui concerne les exigences relatives à la sécurité pour des projets particuliers. Au moment de l’élaboration des systèmes, le Groupe de la sécurité des TI dans la DGIST était en train d’être établi et la vérification n’a pu déterminer qui à l’ASFC était responsable de l’évaluation, de l’examen et de l’approbation des exigences en matière de sécurité.

Réponse de la direction

1. Introduction

1.1 Contexte

La vérification des systèmes en développement de l’ASFC a été déterminée comme une priorité dans le Plan de vérification pluriannuel axé sur les risques de l’ASFC. Ce plan a été approuvé par le Comité de la vérification interne et de l’évaluation le 17 mars 2005.

1.2 Objectifs et étendue

Le principal objectif de la présente vérification était de donner l’assurance nécessaire à l’ASFC que ses pratiques et procédures intégrées de gestion des projets et d’élaboration des systèmes pour les systèmes opérationnels automatisés en développement respectent les politiques et les procédures internes que l’Agence a établies.

Un autre objectif de cette vérification était de cerner les occasions d’améliorer les politiques et les procédures internes en vigueur à l’ASFC en ce qui a trait à la gestion de ses systèmes en développement.

• Phase 1 -- Examen du cadre de contrôle de gestion (CCG) de l’ASFC pour l’élaboration des systèmes opérationnels automatisés
• Phase 2 -- Vérification d’un projet choisi de système en développement
• Phase 3 -- Vérification d’un second projet choisi de système choisi en développement

Les résultats attendus de la vérification pour la phase 1 étaient les suivants :

• Fournir une évaluation de la pertinence et de l’efficacité du CCG actuel de l’ASFC;
• Choisir deux projets en cours d’élaboration de systèmes de l’ASFC en vue d’un examen de la vérification exhaustif touchant leur application des contrôles et des processus de régie actuels. Les deux systèmes en développement ci‑dessous ont été choisis :
  • Phase 2 -- Déclaration de l’information préalable sur les expéditions commerciales - Échange de données informatisé (IPEC - EDI) pour le mode aérien
  • Phase 3 -- Cotation des risques fondée sur l’Information préalable sur les voyageurs/Dossier du passager (IPV/DP)

Les résultats attendus de la vérification pour les phases 2 et 3 étaient les suivants :

• Fournir une évaluation de la mesure dans laquelle les deux projets d’élaboration de systèmes choisis appliquent avec efficacité et de la façon voulue les politiques, les procédures et les méthodes de l’ASFC en ce qui a trait aux projets d’élaboration de systèmes;
• Fournir des recommandations en vue de l’amélioration des politiques et des procédures de l’ASFC pour les projets d’élaboration de systèmes à l’avenir.

L’étendue de cette vérification était d’évaluer l’élaboration de la déclaration IPEC - EDI pour le mode aérien et non l’efficacité de l’application même.

1.3 Critères de vérification

Les critères de vérification utilisés dans la phase 2 ont été élaborés dans la phase 1 de la vérification. Ils ont été élaborés en fonction des éléments de risque inhérents aux projets d’élaboration de systèmes ainsi que des tendances dans le secteur public en ce qui a trait à la régie efficace des cycles de vie des projets d’élaboration de systèmes. Un ensemble de critères de vérification détaillés a été établi et tenait compte des principales influences qui peuvent se répercuter vivement sur les projets d’élaboration de systèmes au gouvernement du Canada (GC) : la structure et les processus de gestion, les politiques et les normes afférentes aux cycles de vie de l’élaboration des systèmes, ainsi que les processus et les procédures de planification et d’acquisition. Ces critères de vérification détaillés ont servi à évaluer les pratiques de l’ASFC.

Il a été constaté pendant la planification initiale de la vérification que les projets d’élaboration de systèmes opérationnels à l’ASFC étaient intrinsèquement exposés à des risques en raison des conditions suivantes :

• L’ASFC a subi une réorganisation en profondeur;
• L’ASFC a dû adopter et adapter des processus distincts d’élaboration de systèmes, y compris des infrastructures de technologie de l’information (TI) distinctes qui ont été établies dans les ministères d’origine (surtout l’ancienne Agence des douanes et du revenu du Canada et Citoyenneté et Immigration Canada);
• L’ASFC se voit imposer des délais de livraison rigoureux de sources extérieures.

Les secteurs de contrôle clés qui s’attaquent aux risques intrinsèques ont été déterminés au moyen du Cadre amélioré de gestion du Secrétariat du Conseil du Trésor du Canada (SCT) et du cadre des objectifs de contrôle dans le domaine de l’information et des technologies connexes (CobiT) de l’IT Governance Institute. Les critères de vérification élaborés pour évaluer les pratiques de gestion, les contrôles généraux et les processus de régie globaux de l’ASFC pour ses projets de systèmes en développement ont été rangés dans les six catégories suivantes :

• Régie
• Avantages opérationnels
• Exigences des utilisateurs
• Gestion des projets
• Solution technique
• Transformation des activités

Les critères de vérification sont présentés à l’annexe A.

1.4 Stratégie et méthodes

La stratégie et les méthodes étaient axées sur les risques et respectaient la Politique sur la vérification interne du SCT. La vérification a été menée conformément à un programme de vérification qui définissait les tâches de celle‑ci pour évaluer chaque critère. Par des entretiens et un examen de la documentation, l’équipe de vérification a pu évaluer les pratiques en vigueur à la lumière des critères et évaluer officiellement l’efficacité de chacune d’entre elles.

Il y a eu des entrevues avec divers représentants de différentes organisations dans la Direction générale de l’innovation, des sciences et de la technologie (DGIST) et avec des représentants des parrains de projet : Direction générale de l’exécution de la loi, Direction générale de l’admissibilité, Direction générale des opérations et Direction générale du contrôle.

Le travail de vérification sur place pour la phase 2 a été effectué entre juillet et octobre 2006.

1.5 Résultats de la Phase 1

Les résultats de la vérification dans la phase 1 ont fait l’objet d’un rapport en février 2007. Un certain nombre de points forts ont été relevés dans les contrôles sur les systèmes en développement. Ces points forts peuvent procurer une solide base à la création d’un CCG rigoureux des systèmes en développement, à savoir une structure de régie et un cadre de gestion des projets. Comme la réorganisation de l’Agence est récente, bon nombre des processus étaient encore au début de leur élaboration et n’étaient pas encore bien éprouvés dans l’organisation. De nouveaux comités étaient en cours de formation, les rôles et responsabilités étaient en train d’être clarifiés et des résultats attendus particuliers étaient en voie d’élaboration. Ces activités indiquent que l’Agence fait des progrès dans l’amélioration de son contrôle sur les systèmes en développement.

Les secteurs de contrôle clés ci‑dessous qui devraient être renforcés ont été mentionnés dans le rapport de vérifiation sur la phase 1 :

• Cadre de gestion des projets -- Ce cadre n’était pas entièrement défini et ne prévoyait pas des processus comme ceux qui suivent :
  • Les jalons d’approbation : des jalons prédéterminés sont établis pour la gestion afin d’évaluer officiellement la concrétisation soutenue des avantages et de fournir une décision d’aller de l’avant ou non.
  • Les rapports sur l’état d’avancement des projets traitant des suivis des coûts eu égard du budget.
  • Les moyens de regrouper des échéanciers de projets distincts en un seul échéancier principal.
• Classement des projets par ordre de priorité -- Le processus qui consiste à remanier les priorités et les ressources dans l’année en cours pour le portefeuille de projets, lorsque de nouvelles initiatives sont lancées, n’était pas suffisant étant donné les limites de la capacité de l’Agence. Le classement des projets par ordre de priorité continue d’être un défi particulier pour l’ASFC. L’Agence n’exerce pas un contrôle intégral sur ses priorités, de manière à laisser tomber ou remanier les priorités existantes à cause des influences et des pressions venant de l’externe.
• Participation des parrains -- Les parrains ne s’étaient pas toujours suffisamment engagés envers le processus d’élaboration du système, particulièrement au niveau de la réception de la conception fonctionnelle, de la mise à l’essai finale et de l’approbation du système avant qu’il n’entre en production, ainsi que de l’examen officiel et de l’accepation des changements dans l’étendue du système.

La direction a examiné le rapport de vérification et a fourni les plans d’action de la direction qui doivent donner suite aux recommandations découlant de la vérification, ainsi que la date d’achèvement établie pour la mise en œuvre de chaque mesure.

1.6 Objet

L'objet du présent document est de présenter les constatations découlant de la phase 2 de la vérification.

2. Vue d'ensemble de la déclaration IPEC - EDI pour le mode aérien

La déclaration IPEC - EDI pour le mode aérien est une composante de l’initiative IPEC qui est une initiative pluriannuelle de plusieurs millions de dollars lancée conformément au Plan d’action des douanes en 2000, avant la formation de l’ASFC en décembre 2003. Le Plan d’action des douanes introduisait un nouveau modèle complet de gestion des risques pour la prestation des programmes, fondé sur les principes de l’information et de l’approbation préalables. Il se composait de 17 initiatives qu’il proposait de mettre en œuvre sur cinq ans. L’initiative IPEC, auparavant appelée Restructuration de la filière des transporteurs, a été lancée en 2000.

L’IPEC visait à fournir à l’ASFC des processus et des instruments plus efficaces de gestion des risques afin de gérer plus efficacement les clients du secteur commercial et leurs expéditions commerciales. L’initiative fournit aux agents de l’ASFC des données sur les expéditions commerciales entrant au Canada avant l’arrivée de celles-ci. Cet accès préalable aux données permet aux agents d’analyser les renseignements avec l’aide d’un instrument automatisé de ciblage et d’évaluation des risques, afin de relever le fret et les expéditions de nature commerciale à risque élevé qui nécessitent un examen plus minutieux à l’arrivée.

L’élaboration de l’IPEC a été séparée en deux composantes concurrentes mais distinctes :

1. L’élaboration de la déclaration électronique de l’information préalable;
2. L’élaboration d’un instrument et d’un processus d’évaluation des risques.

L’équipe de vérification a étudié le projet d’élaboration des systèmes qui portait sur la deuxième composante de l’IPEC, surtout dans le mode aérien. L’IPEC est en activité dans le mode maritime depuis avril 2004 et l’est dans le mode aérien depuis décembre 2005 (sa mise en œuvre s’y est échellonnée jusqu’en juillet 2006). La mise en place dans les derniers modes, routier et ferroviaire, se pousuit grâce au projet Manifeste électronique [1]

La structure organisationnelle de la DGIST [2] au moment où la déclaration IPEC - EDI pour le mode aérien était en train d’être élaborée est reproduite ci-dessous.

ASFC / Innovation, Sciences et Technologie - Structure organisationnelle

Selon cette structure, le projet de déclaration IPEC - EDI pour le mode aérien était géré par un gestionnaire de projet de la Direction de la CEPI et un gestionnaire de projet de TI de la Direction des systèmes frontaliers. Le projet était parrainé par la Direction générale de l’exécution de la loi, la Direction générale de l’admissibilité et la Direction générale des opérations. Pendant l’élaboration de la déclaration IPEC - EDI pour le mode aérien, il y a eu des changements dans le personnel et l’organisation de la DGIST, ainsi que dans les autres directions générales parraines, ce qui a entraîné des défis dans les activités d’élaboration.

Au moment de l’élaboration, de nombreuses pressions ont été exercées sur l’ASFC et la DGIST. Les opérations de l’Agence dépendent grandement des systèmes et de la technologie de l’information, qui sont élaborés, mis en œuvre et gérés par la DGIST. L’ampleur de l’activité d’élaboration des systèmes dans l’ASFC est considérable car des fonds seront consacrés annuellement à l’élaboration et au maintien des systèmes, de l’infrastructure et de la technologie connexe, d’une valeur approximative allant de 150 à 250 millions de dollars, pendant les prochaines années. En réponse aux préoccupations touchant la sécurité en Amérique du Nord, après les attentats terroristes en septembre 2001, le GC a lancé un nombre considérable d’initiatives liées à la sécurité, dans le cadre de l’initiative sur la sécurité publique et l’antiterrorisme (SPAT) et de l’Accord sur la frontière commune (AFC), d’où l’élaboration accélérée d’initiatives. Cela a entraîné des pressions sur un certain nombre de projets d’élaboration de systèmes, notamment la déclaration IPEC - EDI pour le mode aérien.

Bien que le travail d’élaboration de l’initiative IPEC ait commencé avant la formation de l’Agence, l’établissement initial de l’étendue du projet de déclaration IPEC - EDI pour le mode aérien a débuté au début de 2004. Le projet comportait alors dans son étendue les modes aérien et ferroviaire. Le mode ferroviaire a ensuite été retranché de l’étendue du projet et ajouté à celle du projet Manifeste électronique qui est actuellement en élaboration. L’activité de planification initiale du projet de déclaration IPEC - EDI pour le mode aérien a commencé en grande partie après la mise en application dans le mode maritime en avril 2004 [3]. La date de mise en œuvre prévue initialement (tant dans le mode aérien que dans le mode ferroviaire) était le 9 mai 2005 [4], qui a ensuite été reportée au 5 décembre 2005 [5]. Les systèmes de l’IPEC par rapport aux communications électroniques pour le mode aérien sont appliqués depuis le 12 décembre 2005 [6]. Comme une approche graduelle a été utilisée, les transporteurs aériens et les transitaires qui n’étaient pas tout à fait prêts à faire la communication électronique des données à l’ASFC à compter du 12 décembre 2005 ont eu jusqu’au 26 juin 2006 pour se conformer intégralement aux exigences de la déclaration de l’IPEC.

L’initiative IPEC a été financée par les enveloppes de fonds de l’initiative SPATet Manley-Ridge ainsi qu’au moyen d’affectations internes des ressources ministérielles. Même si un budget n’a pas été officiellement établi pour la déclaration IPEC - EDI pour le mode aérien, on estimait les frais d’élaboration à environ 4,7 millions de dollars [7]. L’estimation des coûts comprend tous les coûts de l’AFSC se rapportant à l’élaboration de la déclaration IPEC - EDI pour le mode aérien en 2005‑2006 et 2006‑2007, y compris certains coûts liés au travail d’élaboration dans le mode maritime qui ne pouvaient être isolés aux fins de la présentation.

3. Constatations de la vérification

Par suite du travail de vérification effectué dans la phase 2, il a été conclu que la déclaration IPEC - EDI pour le mode aérien est un projet qui a été élaboré conformément aux politiques, aux procédures et aux méthodes de l’ASFC qui étaient en vigueur à ce moment‑là. En outre, l’application fonctionne de la façon prévue. Toutefois, il existe des occasions de renforcer les processus d’élaboration des systèmes employés dans la déclaration IPEC - EDI pour le mode aérien afin de faire en sorte qu’il y aura une régie, une gestion des risques et un contrôle appropriés dans le cas des projets de systèmes en développement à l’avenir.

Depuis l’élaboration de la déclaration IPEC - EDI pour le mode aérien en 2004 et 2005, de nombreux nouveaux processus et de nombreuses nouvelles pratiques de régie ont été élaborés et introduits pour les projets les plus récents. De plus, de nombreuses observations faites lors de la phase 1 ont été appuyées par la présente vérification de la phase 2. Dans ses plans d’action pour les recommandations découlant de la vérification de la phase 1, la direction indique qu’elle s’est attaqué récemment à de nombreux secteurs de vérification ayant besoin de renforcement ou qu’elle est en train de le faire.

Les constatations découlant de la vérification sont décrites en détail ci‑dessous.

3.1 Élaboration d'une solution technique

La vérification a permis de constater que les méthodes d’élaboration des systèmes de l’ASFC ont été utilisées dans toutes les phases du projet. Les activités clés décrites ci‑dessous ont été exécutées :

• Évaluation de la faisabilité et de la viabilité de la solution.
• Définition des exigences des utilisateurs avec la participation des intervenants.
• Mise à l’essai appropriée.

Le projet a été élaboré en suivant une méthodologie reconnue dans l’industrie, le Processus rationnel unifié (PRU), qui est un processus itératif pour réaliser la conception et la version finales [8]. Dans la vérification, il y a eu examen de divers documents qui démontraient l’exécution de bonnes pratiques d’élaboration pour la solution technique, comme il est à prévoir dans tout processus d’élaboration de systèmes. La conception du système a été décrite dans les documents sur l’étendue du projet, le processus de la phase de lancement et les exigences opérationnelles de haut niveau. Les exigences des utilisateurs ont clairement été décrites et consignées dans le document sur les cas d’utilisation opérationnelle. Les exigences ont ensuite été versées aux documents sur la conception des composantes du système et les cas d’utilisation du système devant être employés par les développeurs du système. La conception technique a été consignée dans un document sur le sommaire de conception de la technologie et dans un document de spécifications techniques. Bon nombre des documents rédigés aux fins de l’élaboration du projet de déclaration IPEC - EDI pour le mode aérien l’ont été à l’aide de modèles qui ont depuis évolué et été remplacés par de nouveaux modèles, mais les objectifs clés des documents demeurent les mêmes. Des employés clés de la DGIST ont participé aux phases de la conception et de l’élaboration initiales. Le groupe de l’architecture d’entreprise a échangé avec le groupe de l’architecture opérationnelle dans la Direction de la CEPI et avec des représentants des parrains dans le but de définir les exigences et d’examiner la faisabilité de la solution technique.

Les exigences des utilisateurs ont été définies avec la participation d’intervenants clés. La Direction de la CEPI a joué un rôle déterminant dans l’établissement des exigences et des priorités de haut niveau. Toutefois, des séances mixtes d’élaboration de l’application ont été organisées avec des représentants des parrains afin d’élaborer le document sur les cas d’utilisation opérationnelle. Le programme anticontrebande de la Direction générale de l’exécution de la loi a fourni une orientation fonctionnelle et une expertise en la matière au projet de déclaration IPEC - EDI pour le mode aérien. L’Unité du commerce électronique dans la Direction de la CEPI a fait bénéficier les développeurs du système de son expérience du travail avec les transporteurs. La vérification a permis de trouver la preuve d’un perfectionnement soutenu des exigences opérationnelles, surtout par des communications sous forme de courriel et des mises à jour des documents du projet. Voulant améliorer son processus d’élaboration des exigences des utilisateurs, la DGIST a commencé à utiliser des « architectes de la convivialité » qui étudient l’interface et comment les gens utilisent le système. Les exigences des utilisateurs peuvent ensuite être améliorées davantage pour rendre le système plus facile à utiliser par les utilisateurs.

Il y a eu une mise à l’essai du projet de déclaration IPEC - EDI pour le mode aérien dans un certain nombre de milieux d’essai différents avant la mise en œuvre. L’essai de mise au point a été fait par le groupe de la TI et comprenait un essai de l’intégrité des données et des bases de données, un essai du fonctionnement, un essai de l’intégration des systèmes, un essai du cycle des opérations et un essai de l’interface avec l’utilisateur. Des cas d’essai ont été projetés, des échéanciers ont été arrêtés, des ressources ont été attribuées et les résultats des essais ont été consignés et résumés. Après l’essai de mise au point, la Direction de la CEPI a procédé à un essai d’acceptation par l’utilisateur (le client) et à un essai opérationnel. Des personnes ne faisant pas partie de la Direction ont été invitées à participer à l’essai d’acceptation par l’utilisateur.

Normalement, une fois l’élaboration et la mise en œuvre terminées, l’application du système passe de l’élaboration à la production, puis est transférée au Groupe des opérations des systèmes à la Direction de la CEPI en vue d’un soutien constant. Le passage est bien contrôlé par des procédures de gestion de la diffusion. Au moment de la vérification, le projet de déclaration IPEC - EDI pour le mode aérien n’avait pas encore été transféré aux Opérations des systèmes. Dans la DGIST, il est de pratique courante qu’un projet d’élaboration de systèmes demeure sous le contrôle du groupe d’élaboration pendant environ un an après la mise en œuvre afin de contrôler les problèmes opérationnels initiaux avant qu’il ne passe aux Opérations des systèmes.

3.2 Transformation des activités

Il y a eu régulièrement des communications et des consultations avec le milieu des transporteurs. Les plans de mise en œuvre ont été communiqués au milieu des transporteurs par des avis des douanes périodiques. Divers groupes de travail ont été mis sur pied avec le milieu des transporteurs pour partager les renseignements sur la mise en œuvre. Un processus officiel était en place pour que les transporteurs planifient d’abord leur mise en œuvre, puis mettent à l’essai leur interface avant qu’ils ne soient autorisés à envoyer des données électroniquement. Des documents sur la mise à l’essai ont été envoyés aux transporteurs pour la mise en œuvre. Il y a eu des conférences avec l’industrie afin de l’informer du processus. L’état de la mise en œuvre et les dates de début de la transmission ont été régulièrement contrôlés par les gestionnaires des dossiers de la Direction de la CEPI affectés à la liaison avec des transporteurs particuliers.

Une structure et des processus officiels ont été mis en place pour le soutien des transporteurs externes. Plus précisément, les transporteurs faisant la déclaration électronique des données sur les expéditions aériennes recevaient un soutien de l’Unité du commerce électronique (UCE) déjà en place dans la Direction de la CEPI. Cette unité est la première ligne de soutien en ce qui a trait aux problèmes de transmission des données et, au besoin, transmet les problèmes au groupe des services de la technologie qui est responsable du contrôle de l’interface externe. Une approche par centre d’appels sert à consigner et à régler les problèmes des transporteurs. Les transporteurs bénéficient d’un soutien sans frais pendant les heures de travail. Le soutien est crucial car l’IPEC est considérée une application de grande disponibilité qui exige un soutien après les heures normales d’ouverture.

3.3 Autorité, responsabilité et responsabilisation

Une charte de projet n’a pas été élaborée afin de spécifier en termes exprès les autorisations et la responsabilisation des différentes directions de la DGIST et celles des parrains du projet. De plus, le parrain officiel n’a pas été clairement énoncé au début du projet. Les gestionnaires de projet ont indiqué trois directions générales différentes à l’équipe de vérification comme parrains non officiels du projet : la Direction générale de l’exécution de la loi, la Direction générale de l’admissibilité et la Direction générale des opérations. Cela a créé un contexte où il y avait plusieurs maîtres d’oeuvre. L’IPEC était une vaste initiative de l’Agence qui s’étendait à de nombreuses organisations internes, et c’est pourquoi la Direction de la CEPI a joué un rôle directeur.

Le parrainage et l’engagement des unités opérationnelles sont considérés un défi courant. Comme dans tout projet d’élaboration, la DGIST et les parrains ont les autorisations et les responsabilités qu’exigent la prise de décisions touchant le projet d’élaboration. Pour ce qui est de la déclaration IPEC - EDI pour le mode aérien, la délimitation des autorisations et des responsabilités n’était pas claire. Cela pourrait être causé, du moins en partie, par la structure historique où la Direction de la CEPI faisait partie du groupe opérationnel et le représentait et détenait l’autorisation globale en tant que parrain pour tous les grands projets d’élaboration de systèmes. Comme les parrains ne s’étaient pas officiellement engagés dès le début du projet, les personnes interrogées ont indiqué que la Direction de la CEPI, par nécessité, avait pris en charge de nombreuses décisions concernant l’élaboration. Des gestionnaires supérieurs provenant des directions générales qui parrainent le projet ont été interrrogées et ont indiqué qu’ils ne s’étaient pas assez intéressés dès le départ à l’élaboration surtout à cause de priorités concurrentielles et d’autres engagements opérationnels. Les directeurs généraux (DG) de ces directions générales ont été informés de l’état des projets du système du secteur commercial par des réunions de comité établies, mais leur présence n’était pas assidue. À mesure que le projet avançait, les directions générales ont participé davantage à la prestation d’une orientation stratégique. Elles sont intervenues particulièrement à la fin de l’élaboration lorsque des questions d’orientation ont été soulevées quant à savoir où et quand il y aurait ciblage -- une composante fondamentale de l’IPEC. Il y a eu une décision de principe importante exigeant une vaste consultation qui n’a pas été prise au début de l’élaboration, comme cela aurait dû se faire. Juste avant la mise en œuvre, il a été décidé de faire un essai pilote de deux approches dans le ciblage; ces approches seront analysées ultérieurement et une décision stratégique finale sera prise à cet égard.

Dans le cas de la déclaration IPEC - EDI pour le mode aérien, les rôles et responsabilités au niveau de l’élaboration dans la DGIST ont été bien compris. Toutefois, au sein de la DGIST, la responsabilisation pour l’exécution fructueuse du projet n’était pas clairement définie aux niveaux supérieurs. Il n’y avait aucun gestionnaire supérieur responsable et comptable de tous les aspects de l’exécution de ce projet particulier. Pendant ce projet, il y a eu deux DG qui ont conjointement rendu compte de son exécution :

• Un DG de la Direction de la CEPI était responsable de toute la planification et de toute la gestion de projet pour tous les projets de systèmes;
• Un DG de la Direction des systèmes frontaliers (TI) était responsable de l’élaboration des applications pour tous les projets de systèmes.

Malgré le manque de clarification des autorisations et de la responsabilisation, les rôles traditionnels et les efforts individuels ont fait que le système a été élaboré avec efficacité. Par suite de la réorganisation, la TI a été combinée avec la Direction de la CEPI et, par conséquent, un DG est maintenant responsable de tous les aspects de l’élaboration des projets et de l’exécution de tous les projets de systèmes du secteur commercial, ce qui devrait améliorer la responsabilisation à l’égard de l’exécution des systèmes en développement pour les projets à l’avenir.

La vérification a permis de constater que les processus de régie évoluent et s’améliorent dans l’ASFC. Pour les projets les plus récents, tel le Manifeste électronique, l’équipe de vérification a été informée qu’un comité directeur des DG a été établi dès le début du projet et devait inclure des membres de la haute direction provenant de toutes les directions générales touchées, y compris les régions. En outre, les autorisations, les responsabilités et la responsabilisation sont clairement définies dans la charte du projet. Ces pratiques sont conformes au nouveau cadre de régie des grands projets qui est en train d’être élaboré. Ce cadre explique l’autorisation, les processsus et la supervision pour toutes les phases d’un projet, y compris la définition des rôles et des responsabilités des parrains, de la haute direction et des gestionnaires, ainsi que des comités organisationnels mis sur pied pour régir les activités du projet.

Des autorisations et la responsabilisation clairement définies au début du projet peuvent aider à voir à ce que les parrains soient suffisamment engagés vis‑à‑vis du projet pour définir et contrôler leurs exigences afin d’obtenir un projet qui répond à leurs besoins. Dans le même ordre d’idées, la responsabilisation pour l’élaboration fructueuse sera claire et, ainsi, une direction sera jugée comptable de l’élaboration fructureuse du projet (c.‑à‑d. dans les délais prévus et sans dépasser le budget tout en respectant les exigences des utilisateurs).

Recommandation :

1. Que la DGIST, de concert avec la Direction générale de l’exécution de la loi, la Direction générale de l’admissibilité, la Direction générale des opérations et la Direction générale du contrôle, s’assure que les autorisations, les responsabilités et la responsabilisation sont clairement définies dès le début de tout projet d’élaboration de systèmes.

3.4 Cadre de gestion des projets

Comme il est mentionné dans le rapport de vérification de la phase 1, un cadre (ou un cycle de vie) de gestion des projets servant à gérer les systèmes en développement est en train d’être mis au point et affiné; il sera assorti d’instruments et de modèles à l’appui pour sa mise en œuvre. Ce cadre n’était pas en place au moment de l’élaboration du projet de déclaration IPEC - EDI pour le mode aérien. Toutefois, le projet a adopté une méthodologie d’élaboration comportant des phases claires, qui s’inspirait de près du cadre en élaboration.

Le rapport de vérification sur la phase 1 faisait état de secteurs où le cadre de gestion des projets pourrait être renforcé ou amélioré. Le travail de vérification dans la phase 2 appuie ces conclusions antérieures. Les observations suivantes ont été faites sur les pratiques de gestion des projets ayant servi lors de l’élaboration du projet de déclaration IPEC - EDI pour le mode aérien.

• Documentation des jalons d’approbation -- La vérification a permis de constater que les décisions d’approbation officielle dans les jalons clés n’étaient pas bien consignées. La vérification n’a pas permis de trouver des documents appuyant les approbations aux jalons clés. Les personnes interrogées ont indiqué que, même s’il n’y avait pas en place un processus d’autorisation officiel au moment de l’élaboration, la décision d’aller de l’avant par un consensus avait été obtenue au sein de l’équipe d’élaboration. Bien qu’il y eût plusieurs groupes de discussion où ont été discutés les progrès de tous les projets, il n’y avait pas de comité directeur qui supervisait les progrès du projet et prenait des décisions propres au projet, y compris les autorisations d’aller de l’avant avec les jalons prédéterminés. Cette lacune dans le processus pourrait être le résultat d’une définition floue des autorisations, des responsabilités et de la responsabilisation pour les projets. Un organisme de supervision efficace qui consigne officiellement et communique les approbations assurera une compréhension commune et une transparence du processus d’élaboration et garantira que des approbations sont reçues selon les besoins.

• Rapports sur l’état d’avancement du projet -- La vérification a permis de constater que l’état d’avancement du projet faisait l’objet de rapports officiels fortement résumés à la haute direction par le tableau de bord pour la direction, un document trimestriel. Toutefois, des rapports normaux sur les progrès du projet (en fonction de l’échéancier, du budget et de son étendue) sous le niveau de la direction n’étaient pas disponibles. Dans la vérification, il y a eu examen de cinq rapports détaillés sur l’état d’avancement du projet, mais ils variaient tous de par leur format et leur fréquence n’était pas la même. À mesure que s’accroissaient des contraintes de temps et que les rapports d’étape à la haute direction évoluaient, les rapports sur l’état d’avancement du projet plus détaillés ont été remplacés par un rapport de haut niveau, le tableau de bord. Les personnes interrogées ont indiqué qu’une plus grande quantité de renseignements était fournie de vive voix sur les progrès du projet lors de diverses réunions officielles et officieuses. Des mises à jour verbales de l’état d’avancement du projet étaient aussi fournies régulièrement à l’équipe de la gestion des nouvelles versions une fois que le projet a été ajouté à l’échéancier des versions. Des rapports normaux sur le projet qui comprennent des renseignements sur les budgets, les échéanciers et l’étendue feront en sorte que la direction ait les renseignements que nécessite une prise de décisions efficace.

• Suivi des coûts -- Une estimation budgétaire unique pour ce projet n’a pu être faite car les affectations à la déclaration IPEC - EDI pour le mode aérien étaient éparpillées et n’étaient pas faciles à distinguer de celles à d’autres sous-projets IPEC et à accumuler. Le système de comptabilisation des coûts de l’ASFC suit les coûts par centre des coûts et il a été conçu de manière à suivre les coûts par la source de financement et non par projet. C’est pourquoi les coûts associés au projet de déclaration IPEC - EDI pour le mode aérien ont été engagés par de nombreux centres des coûts différents et non accumulés ou signalé par projet. Dans les centres des coûts, il y avait une budgétisation courante et des comparaisons des coûts pour montrer les progrès mensuels en fonction du plan, ce qui donne une indication approximative du respect des budgets. Comme c’était la pratique dans les directions de la TI pendant de nombreuses années, tous les employés de l’ASFC sont maintenant tenus de saisir leur temps par code de projet, depuis le 1er avril 2007. Cela devrait permettre une accumulation et un suivi des coûts des projets, permettant ainsi une supervision appropriée des dépenses des projets.

• Planification et échéancier intégrés -- Pendant la vérification, il a été constaté que des plans et des échéanciers de projet existaient chez les principaux groupes d’élaboration, mais ils n’étaient pas intégrés afin de coordonner toutes les diverses tâches d’élaboration et les interdépendances du projet. Un examen des échéanciers de projet maintenus séparément par la Direction de la CEPI et la TI a fait ressortir que les échéanciers n’étaient pas liés ni aménagés en fonction de dates clés comme l’achèvement de la phase d’analyse et de conception. Ce projet faisait intervenir de nombreuses personnes, dont des gestionnaires de projet, des architectes, des gestionnaires des données, des gestionnaires des nouvelles versions et des équipes de la plate-forme électronique des douanes, et les équipes du projet considéraient que les communications verbales courantes utilisées entre les diverses équipes étaient un moyen efficace de coordonner les activités. Toutefois, il y avait une certaine incertitude entourant les dates limites clés pour les changements dans les exigences. Cela aurait pu être mieux communiqué par un plan et un échéancier de projet intégrés. Un plan et un échéancier intégrés feront en sorte que les interdépendances sont clairement comprises et que les dates clés sont prévues dans le but de respecter les dates des nouvelles versions prévues et d’améliorer l’efficacité. La récente réorganisation de la DGIST, qui a regroupé les développeurs de la TI et les gestionnaires de projet de la Direction de la CEPI, devrait améliorer les problèmes d’intégration.

• Concrétisation des avantages -- Les avantages opérationnels de haut niveau pour l’initiative IPEC dans son ensemble étaient compris au sens de la définition que renfermait le Plan d’action des douanes et la présentation originale au Conseil du Trésor en 1999. Il est reconnu que le véritable avantage de la déclaration IPEC - EDI pour le mode aérien viendra de la composante élargie de l’évaluation des risques de l’IPEC pour améliorer le ciblage. Quoi qu’il en soit, les avantages et les résultats opérationnels détaillés du projet de déclaration IPEC - EDI pour le mode aérien n’étaient pas définis de manière à pouvoir pleinement évaluer la concrétisation des avantages généraux du programme IPEC et la contribution à ces avantages. Il n’y avait pas d’analyse de rentabilité qui déterminait la mesure du succès, telles des améliorations de l’efficience et de l’exactitude de l’information, par suite de l’introduction de la déclaration IPEC - EDI pour le mode aérien.

• Gestion du changement -- La vérification du projet de déclaration IPEC - EDI pour le mode aérien a permis de constater que, même si l’étendue du projet était bien définie, le processus et les autorisations d’agrément des demandes de changement ne l’étaient pas. La vérification a révélé que les approbations par les parrains des demandes de changement se faisaient par un échéange itératif de courriels pour discuter la justification d’une demande de changement et qu’il était difficile de déterminer si la personne compétente avait approuvé le changement. Plusieurs représentants des parrains qui ont été interrogés ont également indiqué que le délai d’exécution exigé était parfois trop court pour pleinement examiner le changement ou faire intervenir du personnel supérieur. Une fois que le groupe parrain avait approuvé le changement, il y avait un processus officiel de contrôle du changement à la TI qui servait à examiner le changement et à l’ajouter à l’échéancier des nouvelles versions. Quant aux demandes de changement, la TI faisait sa propre estimation des coûts et priorisait les changements en vue de leur inclusion dans l’échéancier des nouvelles versions, et les demandes de changement étaient suivies par plusieurs groupes différents. Donc, la désignation des demandes de changement variait, ce qui rendait difficile le suivi de demandes de changement particulières. La gestion du changement est une composante cruciale de la gestion des projets qui assure une rigueur suffisante pour éviter un glissement dans l’étendue. Les parrains aimeraient avoir une compréhension plus claire du processus de gestion du changement ainsi que des attentes et des autorisations pour l’approbation des changements. Cette lacune dans le processus pourrait être le résultat d’une définition floue des autorisations et de la responsabilisation pour les projets.

• Gestion des problèmes -- La vérification a permis de constater qu’il y avait en place plusieurs registres servant à suivre les problèmes. Ces registres différaient de par leur format, les problèmes relevés et les systèmes de numérotation. Il n’y avait pas de registre exhaustif actuel et de classement selon la gravité du problème, du moment déterminé du règlement de celui‑ci ou des dépendances notées. Un processus clair de documentation, de suivi et de classement des problèmes dans le processus d’élaboration renforcerait l’assurance donnée à la direction que tous les problèmes sont réglés avec efficacité et efficience.

Dans le rapport de vérification sur la phase 1, il était recommandé que la DGIST poursuive ses plans de mise en œuvre d’un processus qui garantirait que des jalons sont clairement définis et que la concrétisation des avantages est examinée et documentée suivant chaque jalon. La direction avait indiqué que de tels processus seraient mis en place. Il a aussi été recommandé qu’un régime de rapports sur l’état d’avancement des projets et un processus d’analyse de rentabilité soient élaborés, et la direction avait indiqué que de tels processus seraient mis au point.

Recommandation :

2. Que la DGIST, de concert avec la Direction générale de l’exécution de la loi, la Direction générale de l’admissibilité, la Direction générale des opérations et la Direction générale du contrôle, améliore davantage son cadre de gestion des projets de manière à inclure ce qui suit :
   • Un processus officiel d’intégration de la planification et des échéanciers des divers projets au sein de toutes les directions.
   • La définition du processus de gestion du changement et sa communication aux parrains, ainsi que les attentes et les autorisations pour l’approbation des changements.
   • Un processus de documentation, de suivi et de classement des problèmes d’élaboration qui est uniforme dans l’ensemble de la direction générale et débouche sur une solution efficace et efficience des problèmes.

3.5 Gestion des risques du projet

Un processus officiel de gestion des risques associés au projet entraîne la détermination, l’évaluation, le traitement et le contrôle des risques qui pourraient mettre en danger le succès du projet en ce qui concerne la qualité du produit, l’échéancier et les coûts. Les conséquences éventuelles liées aux risques et le degré d’exposition aux risques pouvant être toléré seraient discutés pour déterminer la réponse officielle aux risques (éviter, atténuer, assumer ou transférer/renvoyer au niveau compétent). L’équipe du projet établirait si les risques sont acceptables et ce qui peut et pourrait être fait pour y remédier ou pour mieux les gérer. Un processus officiel de renvoi au niveau compétent garantirait que la haute direction participe à la discussion des risques au moment opportun.

Pour le projet de déclaration IPEC - EDI pour le mode aérien, la vérification a permis de constater qu’on s’attaquait officieusement aux risques sur une base quotidienne, mais que ces risques n’étaient pas bien documentés. Les entretiens ont révélé que, lorsque des risques étaient recensés, ils étaient signalés au gestionnaire de projet compétent lors de réunions courantes. Il n’y avait pas toujours un compte rendu dressé des réunions courantes sur le projet, à l’appui de la documentation des risques et des mesures prises. Un registre ordinaire des risques n’était pas tenu pour le projet afin de contrôler l’exposition aux risques. Depuis l’élaboration du projet, un modèle de registre des risques a été mis au point qui sert à documenter les risques associés au projet.

Dans le rapport de vérification sur la phase 1, il était rcommandé que la DGIST continue ses efforts de mise en œuvre d’une stratégie de gestion des risques à l’appui du cadre de régie des grands projets et du cadre du cycle de vie des projets de la DGIST. La direction a indiqué qu’une telle stratégie serait mise en œuvre.

3.6 Évaluation de la sécurité

Une évaluation de la sécurité pour l’initiative IPEC a été préparée au moyen du modèle voulu de sorte que les aspects clés de la sécurité informatique soient dûment abordés dans le cadre de tous les projets. La documentation ne permettait pas d’établir clairement qui avait examiné et approuvé l’évaluation de la sécurité. Il a été constaté, lors des entretiens, que le processus d’évaluation de la sécurité avait été examiné à l’AFSC par le Groupe de la sécurité des TI dans la DGIST et le Bureau de la sécurité de l’Agence (BSA) dans la Direction générale du contrôle.

Recommandation :

3. Que la Direction générale du contrôle, en collaboration avec la DGIST, continue son examen des processus pour effectuer les évaluations de la sécurité et clarifie le rôle du Groupe de la sécurité des TI et du BSA dans l’évaluation des exigences relatives à la sécurité pour les divers projets, y compris les exigences sur le plan technique, de l’information et de la sécurité matérielle.

Annexe A - Critères de vérification

Voici les critères de vérification utilisés pour la phase 2  :

Annexe B - Liste des acronymes

ACIA

Agence canadienne d'inspection des aliments

AFC

Accord sur la frontière commune

ARC

Agence du revenu du Canada

ASFC

Agence des services frontaliers du Canada

BSA

Bureau de la sécurité de l'Agence

CCG

Cadre de contrôle de gestion

CEPI

Conception et élaboration de projets importants

CIC

Citoyenneté et Immigration Canada

DGIST

Direction générale de l'innovation, des sciences et de la technologie

EDI

Échange de données informatisé

EMR

Évaluation de la menace et des risques

ES

Énoncé de la sensibilité

IPEC

Information préalable sur les expéditions commerciales

PRU

Processus rationnel unifié

SPAT

Sécurité publique et antiterrorisme

UCE

Unité du commerce électronique