Vérification des systèmes de TI en développement - Phase 1
Rapport de vérification interne

février 2007

Table des matières

• Sommaire
• Introduction
  • Contexte
  • Objectifs et étendue
  • Critères de vérification
  • Stratégie et méthode
  • Objet
• Vue d’ensemble du développement de systèmes à l’ASFC
• Constatations de la vérification
  • Cadre de gestion des projets
  • Classement du portefeuille de projets par ordre de priorité
  • Participation des unités opérationnelles
  • Système de gestion de la qualité
  • Gestion des risques
• Annexe A - Critères de vérification
• Annexe B - Liste des acronymes

Sommaire

La vérification des systèmes de TI en développement – Phase 1 de l’Agence des services frontaliers du Canada (ASFC) a été désignée hautement prioritaire 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 et de l’évaluation le 17 mars 2005. La vérification a été exécutée par Interis Conseils Inc. entre mars et mai 2006.

Cette vérification avait pour objectif principal de donner comme il se doit à l’ASFC l’assurance que les pratiques et les procédures intégrées de gestion des projets et de développement des systèmes qu’elle utilise pour ses systèmes opérationnels automatisés en développement respectent les politiques et les procédures internes établies par l’ASFC et le cadre actuel de contrôle de la gestion (CCG), comprenant la régie, la gestion des risques et le contrôle des projets d’élaboration de systèmes de TI. Cette initiative avait en outre pour objectif de cerner les possibilités d’amélioration des politiques et des procédures internes en vigueur à l’ASFC pour la gestion de ses systèmes de TI en développement. Ce rapport expose les constatations découlant de la Phase 1 de la vérification, qui a consisté à examiner le cadre de gestion pour l’élaboration de systèmes opérationnels automatisés.

Constatations de la vérification

Sur la base des travaux réalisés au cours de la Phase 1, la vérification a permis de relever qu’un cadre de contrôle de gestion pour le développement de systèmes opérationnels automatisés était en place, mais qu’il était possible de le renforcer pour assurer une régie, une gestion des risques et un contrôle adéquats sur les projets d’élaboration de systèmes de TI. Les conclusions qui ont été tirées au cours de cette phase de la vérification seront examinées plus à fond sous l’angle de leur incidence dans le cadre de la Phase 2 et de la Phase 3.

La vérification a permis de relever, au chapitre des contrôles exercés sur les systèmes de TI en développement, des points forts qui peuvent servir de base à l’établissement d’un cadre solide de contrôle de gestion des systèmes de TI en développement, comprenant notamment une structure de régie et un cadre de gestion des projets. Étant donné que la restructuration de l’Agence est récente, un grand nombre de processus n’en sont encore qu’aux premiers stades de leur élaboration et n’ont pas encore atteint leur plein développement dans l’organisation. De nouveaux comités sont mis sur pied, les rôles et les responsabilités sont clarifiés et des résultats attendus précis sont élaborés. Ces activités témoignent des progrès que l’Agence accomplit dans l’amélioration du contrôle qu’elle exerce sur les systèmes de TI en développement.

Les principaux aspects du contrôle qui doivent être renforcés sont les suivants :   

• Cadre de gestion des projets – Le cadre de gestion des projets n’est pas entièrement défini et ne comporte pas les processus suivants :
  • des jalons d’approbation préétablis pour que la direction puisse évaluer en bonne et due forme la concrétisation continue des avantages et prendre la décision d’aller de l’avant ou de ne pas aller de l’avant; 
  • des rapports sur l’état d’avancement du projet pour faire le suivi des coûts du projet en regard du budget;
  • des processus permettant de regrouper les calendriers de projets individuels en un calendrier principal.
• Classement des projets par ordre de priorité – Le processus permettant de réorienter, en cours d’exercice, les priorités et les ressources pour le portefeuille des projets lorsque de nouvelles initiatives sont lancées ne suffit pas, compte tenu des capacités restreintes de l’Agence. Le classement des projets par ordre de priorité pose un défi particulier à l’Agence. L’Agence n’exerce pas sur ses priorités un contrôle total qui lui permettrait de laisser tomber ou de réajuster les priorités existantes compte tenu des influences et des pressions de l’extérieur.   
• Participation de l’utilisateur final – L’utilisateur final ne prend pas toujours suffisamment part au processus d’élaboration des systèmes, particulièrement en ce qui touche l’acceptation de la conception fonctionnelle, la mise à l’essai définitive et les approbations du système avant sa mise en service, et l’examen et l’acceptation en bonne et due forme des changements apportés à l’étendue des travaux. 

Réponse de la direction

La direction a fait un examen sérieux du présent rapport et a fourni des plans d’action de la direction qui répondent aux recommandations de la vérification ainsi que la date prévue d’entrée en vigueur de chaque mesure.

1.0 Introduction

1.1 Contexte

La vérification des systèmes de TI en développement de l’ASFC a été désignée hautement prioritaire 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 et de l’évaluation le 17 mars 2005. La vérification a été exécutée par Interis Conseils Inc. entre mars et mai 2006.

1.2 Objectifs et étendue

Cette vérification avait pour objectif principal de donner comme il se doit à l’ASFC l’assurance que les pratiques et les procédures intégrées de gestion des projets et de développement des systèmes qu’elle utilise pour ses systèmes opérationnels automatisés en développement respectent les politiques et les procédures internes établies par l’ASFC et le cadre actuel de contrôle de la gestion (CCG) de la Direction générale de l’innovation, des sciences et de la technologie (DGIST), comprenant la régie, la gestion des risques et le contrôle des projets d’élaboration de systèmes.

Cette initiative avait en outre pour objectif de cerner les possibilités d’amélioration des politiques et des procédures internes en vigueur à l’ASFC pour la gestion de ses systèmes de TI en développement.

Aux fins de l’atteinte de ces objectifs, le plan de vérification interne a été divisé selon les trois phases suivantes :

• Phase 1- Examen du cadre de gestion de la DGIST pour l’élaboration de systèmes opérationnels automatisés
• Phase 2 - Vérification d’un système en développement choisi
• Phase 3 - Vérification d’un système en développement choisi

Le résultat attendu de la Phase 1 de la vérification était le suivant :

• présenter une évaluation de la pertinence et de l’efficacité du cadre actuel de contrôle de gestion de l’ASFC, qui portera entre autres sur les pratiques actuelles de gestion de l’élaboration des projets et des systèmes à l’ASFC;
• sélectionner deux projets d’élaboration de systèmes en cours à l’ASFC afin d’examiner plus globalement la façon dont l’Agence applique les contrôles et les processus de régie en place.

Les résultats attendus de la Phase 2 et de la Phase 3 de la vérification sont les suivants :

• présenter une évaluation de la mesure dans laquelle les éléments suivants sont appliqués de manière efficace et appropriée dans le cadre des deux projets d’élaboration de système sélectionnés :
  • les politiques et les procédures internes de l’ASFC concernant les projets d’élaboration de systèmes;
  • la méthode interne d’élaboration des systèmes de l’ASFC;
• formuler des recommandations visant à améliorer les politiques et les procédures appliquées à l’ASFC pour les futurs projets d’élaboration de systèmes.

1.3 Critères de vérification

Les critères de vérification pour cette initiative en deux volets ont été définis en fonction des éléments de risque qui vont de pair avec les projets de développement de systèmes et des tendances dans le secteur public en matière de régie efficace des cycles de vie de tels projets. Un ensemble détaillé de critères de vérification a été établi, compte tenu des principales influences qui peuvent jouer fortement dans les projets de développement des systèmes au gouvernement fédéral, c.‑à‑d. la structure et les processus de gestion, les politiques et les normes relatives au cycle de vie du développement des systèmes, ainsi que les processus et les procédures de planification et d’acquisition. Les critères de vérification détaillés ont été utilisés pour évaluer les pratiques de l’ASFC. Ces critères de vérification formeront la base d’une évaluation plus exhaustive des deux projets d’élaboration de système opérationnel qui ont été sélectionnés (c.‑à‑d. la Phase 2 et la Phase 3).

On a constaté, au cours de la planification préalable de la vérification, que les projets de développement de systèmes opérationnels à l’ASFC étaient par essence exposés au risque compte tenu des conditions suivantes :

• la méthode de développement de systèmes a été unifiée de manière à inclure aussi bien l’étape de la gestion du projet que celle du cycle de développement des systèmes;
• l’ASFC a subi une restructuration en profondeur;
• l’ASFC a dû adopter et adapter des processus distincts de développement de systèmes, y compris des infrastructures de TI différentes qui avaient été établies par les ministères qu’elle a remplacés (principalement l’Agence du revenu du Canada [ARC] et Citoyenneté et Immigration Canada [CIC]);
• l’ASFC doit faire face aux défis que lui posent des délais de livraison souvent rigoureux qui lui sont imposés de l’extérieur.

Les principaux secteurs de contrôle visant à atténuer les risques inhérents ont été déterminés à l’aide du Cadre amélioré de gestion du Conseil du Trésor (CT) 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 à utiliser pour évaluer au préalable l’ensemble des pratiques opérationnelles, des contrôles généraux et des processus de régie que l’ASFC applique à ses projets de développement de systèmes de TI ont été classés en six catégories :

• Régie
• Avantages pour l’organisation
• Besoins des utilisateurs
• Gestion du projet
• Solution technique
• Transformation des activités

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

1.4 Stratégie et méthode

La stratégie et la méthode étaient fondées sur les risques et se conformaient à la Politique sur la vérification interne du Secrétariat du Conseil du Trésor (SCT) et aux normes de l'Institut de la vérification interne (IVI). La vérification a été exécutée conformément au programme de vérification qui définit les tâches à accomplir pour évaluer chaque critère. Grâce à des entrevues et à un examen des documents, nous avons évalué les pratiques en vigueur en regard des critères et nous avons évalué officiellement l’efficacité de chaque pratique.

Des représentants de la DGIST, émanant entre autres de Planification et Architecture, de Conception et élaboration de projets importants, des Systèmes des services frontaliers et des Services technologiques, ont été rencontrés en entrevue.

La Phase 1 de la vérification a été réalisée entre mars et mai 2006.

1.5 Objet

Le présent document a pour objet de présenter les constatations découlant de la Phase 1 de la vérification.

2.0 Vue d’ensemble du développement de systèmes à l’ASFC

L'Agence des services frontaliers du Canada (ASFC) a été créée en décembre 2003 et regroupe la Direction générale des douanes de l’ancienne Agence des douanes et du revenu du Canada (ADRC), ainsi que des parties des directions générales des Appels et de l'Observation qui appuyaient les Douanes, le programme du renseignement, de l'interception et de l'exécution de la loi de CIC et le programme de l'inspection des importations aux points d'entrée de l'Agence canadienne d'inspection des aliments (ACIA). En octobre 2004, les fonctions liées à l’immigration aux points d'entrée ont également été transférées à l'ASFC. L'Agence fait partie du nouveau portefeuille de la Sécurité publique et de la Protection civile. Sa mission est d'assurer la sécurité et la prospérité du Canada en gérant la circulation des personnes et des marchandises au pays, à l'arrivée et au départ. L’Agence est chargée d’assurer et de contrôler l’application d’environ 90 lois et règlements nationaux pour le compte d’autres ministères et organismes fédéraux, de même que des accords internationaux. L’Agence gère 1 200 points de service et est présente à 40 endroits à l’étranger. Son budget pour 2005-2006 totalise près de 1,12 milliard de dollars et son effectif compte plus de 12 000 employés. 

L’Agence a pour mission de faciliter la circulation des marchandises et des personnes lorsqu’elles arrivent au Canada ou qu’elles en sortent de manière à assurer la prospérité économique du pays, tout en veillant à résoudre les questions de la sécurité et de la sûreté.

Les activités de l’Agence dépendent fortement des systèmes et des technologies de l’information, qui sont élaborés, mis en œuvre et gérés par la Direction générale de l’innovation, des sciences et de la technologie (DGIST). La structure organisationnelle de l’ASFC et de la DGST [ 1 ] est exposée ci‑dessous.

ASFC - Innovation, Sciences et Technologie
Structure organisationnelle

Au moment de la création de l’ASFC, la Direction de la conception et de l’élaboration des projets importants (CEPI) a été transférée telle quelle de la Direction générale des douanes de l’ADRC à la Direction générale de l’innovation, des sciences et de la technologie (DGIST). Il y a alors eu regroupement des directions opérationnelles, y compris CEPI qui représentait par le passé le responsable des projets et en relevait, et des directions de TI sous la direction du même vice-président. La mise au point définitive de la structure organisationnelle de la DGIST n’est pas terminée. Par exemple, l’organisation de la fonction d’architecture est en cours d’examen étant donné qu’elle est actuellement scindée entre deux directeurs généraux. 

L’activité de développement de systèmes à l’ASFC a une grande portée, des dépenses annuelles de l’ordre de 150 à 250 millions de dollars devant être consacrées au cours des prochaines années à l’élaboration et à la tenue des systèmes, de l’infrastructure et de la technologie connexe. On recense à l’heure actuelle 32 projets de systèmes importants, pour la plupart des projets d’élaboration de système, dans le plan de la DGIST, de même que de nombreux autres qui sont considérés comme de futurs projets possibles. Les projets de systèmes sont regroupés en trois catégories, comme le montre le tableau ci‑dessous :

Tous les projets de systèmes commerciaux et ceux concernant les personnes visent à appuyer les Directions générales de l’exécution de la loi et de l’admissibilité, qui agissent seules ou ensemble comme parrains des projets. De nombreux projets portent sur plusieurs années, sont dotés de budgets s’élevant à plusieurs millions de dollars et sont morcelés en de multiples sous‑projets qui ont évolué et ont pris de l’ampleur au fil de la réalisation du projet. Un grand nombre de ces initiatives est dicté par des facteurs externes et fait suite à l’évolution des politiques gouvernementales. 

Depuis sa création, l’Agence a été mise au défi d’intégrer des environnements de développement de systèmes disparates permettant de gérer des questions opérationnelles complexes tout en donnant suite à des initiatives fort diverses. L’Agence utilise actuellement différentes méthodes de développement de systèmes en raison de la réorganisation, mais elle travaille à l’adoption d’une seule norme, la méthode appelée Rational Unified Process [ 3 ] . Le processus de développement de systèmes est fortement régi par des échéanciers imposés et le cycle de production des versions finales. On produit actuellement de deux à quatre versions principales chaque année. Une grande partie de l’infrastructure de TI de l’ASFC continue d’être prise en charge par l’ARC.

3.0 Constatations de la vérification

Sur la base des travaux réalisés au cours de la Phase 1, la vérification a permis de relever qu’un cadre de contrôle de gestion pour le développement de systèmes opérationnels automatisés était en place, mais qu’il était possible de le renforcer pour assurer une régie, une gestion des risques et un contrôle adéquats sur les projets de systèmes de TI en développement. Les constatations découlant de la Phase 1 de la vérification sont expliquées ci-dessous. Les critères de vérification seront examinés plus à fond sous l’angle de leur incidence au cours de la Phase 2 et de la Phase 3 de la vérification. 

3.1 Cadre de gestion des projets

Un cadre de gestion des projets (ou cycle de vie) permettant de gérer les systèmes en développement est en cours d’élaboration, et il est enrichi d’outils et de modèles qui en facilitent la mise en œuvre. Le cadre est actuellement rendu conforme aux étapes de projet définis dans le Cadre amélioré de gestion du CT pour les projets de TI. Les six étapes principales des projets d’élaboration de systèmes à l’ASFC sont définies de la façon suivante : 

• Lancement – les principaux extrants de l’étape sont une analyse de rentabilisation « conceptuelle », un énoncé de l’étendue des travaux approuvé et une charte de projet approuvée.
• Faisabilité et planification – le principal extrant de l’étape est un rapport sur la faisabilité et les options, qui renferme une mise à jour de l’analyse de rentabilisation et une estimation des coûts de catégorie D.
• Analyse et conception – les principaux extrants de l’étape sont la version définitive de l’analyse de rentabilisation approuvée (avec une estimation des coûts de catégorie A), et les besoins approuvés (tels que définis dans les cas d’utilisation opérationnelle et les cas d’utilisation des systèmes).
• Construction (élaboration et essai) – les principaux extrants de l’étape sont les plans de mise en œuvre approuvés, les demandes de modification, les protocoles de test et leurs résultats et la solution définitive prête à être mise en œuvre.
• Mise en œuvre – les principaux extrants de l’étape sont la formation, le déploiement de la solution et les mesures correctives.
• Après mise en œuvre – l’extrant principal de l’étape est l’examen après mise en œuvre.

Ce cadre fournit les bases de l’établissement d’un cadre solide de contrôle de gestion des systèmes en développement. Il existe, pour certains extrants, des modèles fondés sur les processus de l’ARC. Les modèles et les processus nouveaux se rapportant aux premières étapes de l’élaboration sont utilisés pour un grand nombre de projets plus récents. Toutefois, étant donné le caractère récent de la réorganisation de l’Agence, de nombreux processus et modèles de document en sont encore aux premières étapes d’élaboration et n’ont pas encore été implantés. Cette situation est propre aux nouvelles organisations dont les processus n’ont pas encore atteint leur plein développement. Ces activités montrent néanmoins que l’Agence accomplit des progrès dans l’amélioration du contrôle qu’elle exerce sur les systèmes en développement.  

La vérification a permis de constater que le cadre de gestion des projets pourrait bénéficier de la mise en œuvre ou de l’amélioration des composantes suivantes :

• Jalons d’approbation – Le cadre de gestion des projets de l’ASFC divise le travail d’élaboration des systèmes en étapes claires. Toutefois, ce cadre bénéficierait de l’établissement de jalons prédéterminés où la direction est appelée à évaluer en bonne et due forme la concrétisation continue des avantages et à décider d’aller de l’avant ou de ne pas aller de l’avant. Les vérificateurs ont constaté que des décisions d’approbation étaient prises au début du projet et d’une manière informelle à divers moments au cours du développement, mais non à des points précis avant le passage ou non à une autre étape, et que les décisions n’étaient pas bien consignées par écrit. S’il existait un processus de jalonnement officiel, nous nous attendrions à ce que les principaux critères utilisés pour évaluer le succès éventuel d’un projet au moment de l’atteinte de chaque jalon soient résumés pour être présentés aux cadres supérieurs et que les décisions de ces derniers soient clairement consignées par écrit et communiquées. Un processus officiel de jalonnement de l’approbation assorti de jalons prédéterminés réduirait au minimum le risque que l’on poursuive le financement d’un projet lorsque ses avantages ne se concrétisent pas ou lorsque le projet ne produit pas les résultats attendus.
• Rapports sur l’état d’avancement du projet – Il est fait état de l’avancement du projet dans le tableau de bord trimestriel de la direction (« tableau de bord »), qui précise la situation du projet (feux vert, jaune et rouge), laquelle est déterminée d’une manière informelle. Le tableau de bord présente des données sommaires de haut niveau sur les retards par rapport au calendrier et sur les changements apportés à l’étendue des travaux. En complément du tableau de bord, des présentations sont faites sur demande au Comité de l’innovation, des sciences et de la technologie ou à d’autres comités de régie afin de faire ressortir les changements par rapport au tableau de bord précédent et de déterminer les projets présentant les risques les plus élevés (feux jaune ou rouge). Nous avons constaté cependant que le rendement financier par rapport aux budgets ne figurait pas au tableau de bord ou aux présentations que nous avons examinées. Une bonne pratique de gestion consisterait à fournir à la direction tous les renseignements sur l’état d’avancement d’un projet, y compris le rendement par rapport aux budgets, aux fins de l’efficacité de la prise de décisions.
• Suivi des coûts – C’est au niveau du centre de responsabilité que l’on examine les coûts afin de relever les projets qui présentent un déficit ou un excédent. Les coûts des projets individuels sont précisés à ce niveau, mais ils ne sont pas déterminés ni suivis de façon distincte. En outre, les coûts de chaque projet mettant en cause deux centres de responsabilité ou plus ne sont pas cumulés. Faire le suivi des coûts totaux des projets pour tous les centres de responsabilité permettrait une surveillance adéquate de sorte que les problèmes de coûts qui pourraient se poser puissent être relevés suffisamment tôt pour être soumis à la haute direction.
• Calendrier principal – La planification et l’ordonnancement des ressources figurent au calendrier de la version, qui englobe tous les projets planifiés pour la prochaine version ultérieure. Toutefois, la vérification a permis de constater que le calendrier de la version de diffusion est davantage axé sur le déploiement de systèmes particuliers en vue de la prochaine version, plutôt que sur l’intégration des calendriers de projet aux fins de la gestion des ressources à long terme. Il n’y a pas de calendrier principal des projets qui comprenne les calendriers de projets individuels et qui indique les étapes clés et les interdépendances. Un calendrier principal pourrait, par son intégration, améliorer l’affectation des ressources à long terme et la détermination des interdépendances et des économies. 
• Concrétisation des avantages – Les avantages pour l’organisation sont indiqués dans l’analyse de rentabilisation et ils gagneraient à être mieux définis, en précisant par exemple les facteurs de réussite clés, les contrôles mesurables et les calendriers de l’avancement attendu qui peuvent aider au suivi de tous les projets. Par suite de longues entrevues et d’une étude exhaustive d’une analyse de rentabilisation particulière, nous avons établi que les avantages pour l’organisation n’étaient pas analysés à fond ni précisés dans la documentation. On procède dans certains cas à un examen après mise en œuvre afin d’évaluer la concrétisation des avantages, mais une procédure officielle permettrait d’indiquer comment les avantages pour l’organisation devraient être définis au début du projet, puis faire l’objet d’un suivi de sorte qu’on puisse vérifier s’ils se sont concrétisés.

Recommandation

1. La direction de l’Agence devrait poursuivre la mise au point de son cadre de gestion des projets, qui renferme ce qui suit :
   1. l’évaluation officielle par la direction à des jalons préétablis afin d’assurer la concrétisation continue des avantages et la prise d’une décision officielle d’aller de l’avant ou de ne pas aller de l’avant. L’approche des jalons d’approbation du projet devrait être fondée sur les risques de sorte que les projets plus importants présentant des risques plus élevés nécessitent un examen plus rigoureux que les projets moins importants à faibles risques;  
   2. un régime de rapports sur l’état d’avancement des projets de sorte que les gestionnaires de projet fournissent régulièrement des renseignements sur le rendement des projets aux fins des budgets (outre les renseignements sur le calendrier et sur l’étendue des travaux qui font actuellement l’objet de rapports). Les rapports financiers devraient comprendre des données financières quantitatives telles que la provenance des fonds, les dépenses à ce jour, les prévisions de coûts jusqu’à la fin de l’exercice et les déficits et les excédents prévus; 
   3. un processus permettant de faire un suivi régulier du total des coûts du projet dans tous les centres de responsabilité de sorte que les déficits (ou les excédents) projetés de chaque projet puissent être déterminés et examinés à temps;
   4. un régime de planification des projets qui comprend l’établissement et la mise à jour régulière d’un calendrier principal unifié des projets qui indique les principaux résultats attendus et les interdépendances entre les projets;
   5. un cadre de concrétisation des avantages qui permet de définir clairement les avantages au tout début dans le cadre du processus de sélection et d’en faire le suivi pour qu’on puisse déterminer s’ils se sont finalement concrétisés. 

3.2 Classement du portefeuille de projets par ordre de priorité

Les priorités du portefeuille de projets sont établies de façon itérative grâce à des négociations à tous les niveaux, mais surtout dans le cadre de la gestion du calendrier de la version diffusée. Cependant, le classement des projets par ordre de priorité pose un défi particulier à l’Agence. De nouveaux projets sont lancés par suite de nouvelles initiatives de l’ASFC, mais aussi par suite d’influences ou de pressions de l’extérieur. Même lorsque de nouveaux projets sont amorcés, les projets existants demeurent souvent une priorité absolue. C’est pourquoi l’Agence éprouve de la difficulté à réajuster ses priorités de manière à abandonner ou à modifier des projets existants. Néanmoins, l’Agence a des capacités limitées de sorte que les ressources risquent d’être réparties de façon trop clairsemée et que les délais d’exécution pourraient s’allonger. L’équipe de vérification a appris que les priorités faisaient l’objet de discussions régulières au sein du Comité de l’innovation, des sciences et de la technologie, mais aucun document sur les priorités ou les décisions n’a été fourni. L’Agence gagnerait à disposer d’un processus officiel qui lui permette de cerner, d’évaluer et de communiquer les risques et les conséquences que présente, pour le portefeuille de projets, le lancement de nouvelles initiatives en cours d’exercice de manière à pouvoir prendre des décisions éclairées sur la poursuite des priorités.

Le classement prioritaire du développement de systèmes n’est pas toujours dicté par la stratégie ou la vision à long terme de l’ASFC. Bien que les besoins opérationnels et les objectifs des directions générales fassent l’objet d’un suivi à divers niveaux, ils ne sont pas regroupés dans l’intérêt de la planification des systèmes à long terme. Un modèle officiel de gestion des relations avec la clientèle qui permette d’assurer une liaison avec les groupes opérationnels en vue de déterminer et de regrouper les besoins opérationnels faciliterait la fonction de planification. On a récemment préparé un calendrier de planification afin de déterminer les versions des systèmes prévues pour l’exercice 2006‑2007 en cours, mais il faudrait étendre le calendrier sur plus d’un exercice pour qu’on puisse voir quand de nouveaux projets peuvent être entrepris.

Recommandations

La direction de l’Agence devrait :

2. établir un processus officiel qui permette d’évaluer pleinement les risques et les conséquences que présente, pour le portefeuille de projets, le lancement de nouvelles initiatives en cours d’exercice pour que la haute direction puisse prendre des décisions sur le réajustement des priorités et sur la réorientation des ressources;
3. s’assurer que les besoins en systèmes des groupes opérationnels sont cernés, classés par ordre de priorité et planifiés suffisamment tôt.

3.3 Participation des unités opérationnelles

La régie des systèmes de TI en développement est en évolution à l’ASFC étant donné que le rôle des unités opérationnelles dans le processus de développement n’a pas été entièrement établi et que les relations sont encore en train d’être créées. De nombreux cadres supérieurs sont nouvellement arrivés à l’ASFC et ne connaissent pas bien les ministères que celle-ci a remplacés.

À la DGIST, il existe une structure de régie qui amène les directeurs généraux et les directeurs de toutes les directions à se réunir régulièrement pour discuter des activités de projet. En conséquence, les communications et les relations au sein de la DGIST ont fini par améliorer le degré de surveillance des projets à l’intérieur de la direction générale. La DGIST compte les comités suivants qui sont chargés de discuter des systèmes de TI en développement :

• Forum des directeurs généraux de la DGIST - son mandat consiste à discuter des questions et des risques liés à la gestion des projets et à faire connaître l’état d’avancement des projets. Il regroupe tous les directeurs généraux de la DGIST.
• Forum des directeurs de la DGIST - son mandat est analogue à celui du Forum des DG de la DGIST, mais il regroupe tous les directeurs de la DGIST. 
• D’autres comités de gestion des projets et comités techniques sont mis sur pied pour gérer l’avancement des projets individuels et les questions et les risques techniques et pour en discuter. 

Les unités opérationnelles prennent officiellement part au développement des systèmes par l’entremise des comités suivants :

• Comité de l’innovation, des sciences et de la technologie (CIST) - son mandat consiste à examiner les projets importants et à rendre des décisions à leur sujet, et il regroupe les membres du Comité de gestion de la haute direction.
• Réunions de groupe de directeurs généraux en vue de discuter des projets de la DGIST concernant les voyageurs ou les marchandises ou les projets d’ordre général; y assistent les directeurs généraux intéressés des directions générales opérationnelles et de la DGIST. On y discute de l’état d’avancement et des risques de nombreux projets tout au long de l’élaboration des systèmes.
• Équipes de projet – dans certains cas, les représentants des unités opérationnelles participent aux travaux des équipes de projet pendant toute la durée du développement du système.

La représentation et la participation des unités opérationnelles pendant le cycle de vie du projet sont déterminées par le parrain du projet désigné et sont décrites dans la charte du projet. Les parrains de projet et d’autres représentants des unités opérationnelles jouent généralement, au tout début du projet, un grand rôle dans la préparation de l’analyse de rentabilisation et la détermination des exigences, mais leur implication diminue au cours des étapes de développement et de mise à l’essai. Les unités opérationnelles bénéficient d’un soutien à la fin du développement du système grâce à la formation dispensée par CEPI en vue de la mise en œuvre des nouveaux projets de systèmes. On recourt sur une base sélective aux formateurs et aux installations de formation de Rigaud (Québec). L’utilisateur final obtient de l’aide grâce à une fonction de bureau d’aide où l’utilisateur peut téléphoner quand il a des questions ou des problèmes.

La vérification a permis de relever des étapes du développement auxquelles les unités opérationnelles ne participent généralement pas :

• Acceptation de la conception fonctionnelle - Bien que les représentants des unités opérationnelles puissent prendre part aux discussions portant sur la conception fonctionnelle, c’est le gestionnaire de projet issu de CEPI qui accepte la conception fonctionnelle par une signature officielle tenant lieu d’approbation, et non le parrain du projet. CEPI fait participer l’unité opérationnelle au cours de la phase de lancement et la représente au moment de l’approbation des cas d’utilisation opérationnelle. Des améliorations pourraient être apportées aux documents sur les exigences opérationnelles pour que ceux‑ci comprennent une section pour les approbations ou les signatures d’approbation. Une signature d’approbation officielle du parrain du projet émanant de l’unité opérationnelle démontrerait que ce dernier a directement participé à la conception détaillée et qu’il est d’accord avec les exigences et la solution mise en œuvre.   
• Mise à l’essai - Selon les personnes interrogées, les membres de l’équipe de CEPI procèdent aux essais et les représentants de l’unité opérationnelle ne jouent généralement aucun rôle dans les derniers essais et les approbations du système avant que celui‑ci ne soit mis en service. Faire participer les utilisateurs aux derniers essais d’acceptation garantirait que le système répondra à leurs besoins et permettrait d’apporter des modifications avant sa mise en service.
• Contrôle des changements - Un comité consultatif sur les changements a été mis sur pied au sein de la direction de la TI pour évaluer et approuver les changements. Toutefois, les parrains de projet ou les représentants des unités opérationnelles ne prennent généralement pas part à l’examen et à l’acceptation en règle des changements apportés à l’étendue des travaux. Les demandes de modification sont officiellement consignées sur un formulaire standard et portent l’approbation de personnes appartenant à la direction de la TI. Les changements concernant l’étendue des travaux font l’objet d’abondantes discussions au sein de la DGIST, et sont souvent examinés de manière informelle avec le parrain du projet. Un processus officiel permettant de faire participer les unités opérationnelles à la détermination et à l’évaluation de l’incidence du changement contribuerait à garantir que toutes les répercussions de la demande de modification sur les coûts, les délais et l’étendue des travaux sont évaluées, comprises et consignées.

Grâce à la participation de l’unité opérationnelle aux étapes clés du développement, les parrains des projets seront pleinement informés de la solution finale qui est élaborée, de sorte que celle-ci répondra finalement à leurs besoins et à leurs attentes.

Un groupe de travail pour l’accroissement et le renforcement des partenariats externes a récemment été créé dans le cadre de la nouvelle initiative de trousse pour les partenariats de la DGIST en vue d’élaborer des stratégies, des mécanismes et un plan d’action visant à améliorer les partenariats et les relations au sein de l’Agence. Le groupe de travail a relevé la nécessité de disposer d’un solide modèle de régie d’application uniforme pour assurer la bonne marche et la réussite des projets importants. Un thème clé véhiculé par le groupe avait trait à la nécessité de faire participer les partenaires du programme aux décisions sur l’étendue des nouvelles initiatives à l’étape du lancement. L’une des recommandations du groupe portait sur la nécessité d’identifier les partenaires afin de circonscrire clairement les rôles, les responsabilités et les processus permettant de les mettre à contribution et de s’assurer d’obtenir des résultats satisfaisants pour toutes les parties.

Recommandation

4. La direction de l’Agence devrait améliorer les processus afin de mieux faire participer l’unité opérationnelle au développement du système à l’occasion :
   1. l’approbation finale des cas d’utilisation opérationnelle;
   2. l’approbation finale des essais d’acceptation par l’utilisateur;
   3. des travaux d’un conseil de contrôle sur les changements établi en bonne et due forme et doté de critères officiels pour l’approbation des changements après étude de toutes leurs répercussions.

3.4 Système de gestion de la qualité

Le Bureau de gestion du projet (BGP) de la Direction de la planification et de l’architecture produit, sur une base trimestrielle, une information sur les projets de haut niveau à l’intention des cadres supérieurs par l’entremise du tableau de bord de la direction, mais il ne remplit pas un rôle d’assurance de la qualité. Les processus de gestion de la qualité favorisant le respect des exigences du cadre de gestion des projets varient d’un gestionnaire de projet à l’autre. La responsabilité globale relative à l’assurance de la qualité pour tout le portefeuille de projets n’a pas été attribuée. 

Une fonction d’assurance de la qualité nécessiterait la collecte de renseignements détaillés sur les projets, tels que la réalisation des budgets, les résultats attendus prévus et l’exécution de l’étendue des travaux, en vue d’en faire rapport ou d’en communiquer les points saillants à la haute direction. Une telle activité permettrait de garantir que les comités de gestion des projets et les comités directeurs compétents sont suffisamment bien informés des projets qui risquent de dépasser les limites du budget, de ne pas respecter les délais ou de ne pas porter sur toute l’étendue des travaux.

Recommandation

5. La direction de l’Agence devrait instaurer un programme d’assurance de la qualité qui prévoit l’attribution des responsabilités pour les projets individuels et pour l’ensemble du portefeuille de projets.

3.5 Gestion des risques

Un processus officiel de gestion des risques liés aux projets comporte la détermination, l’analyse, l’atténuation et le suivi des risques susceptibles de compromettre la réussite du projet eu égard à la qualité du produit, au calendrier et aux coûts. Les conséquences pouvant découler des risques et le degré de tolérance aux risques seraient analysés, ce qui permettrait de déterminer les mesures officielles à prendre à leur égard (les éviter, les atténuer, les assumer ou les transférer/transmettre aux échelons supérieurs). L’équipe de projet déterminerait si les risques sont acceptables et ce qu’on peut et pourrait faire pour y remédier ou mieux les gérer. Un processus de recours aux échelons supérieurs garantirait que la haute direction participe aux discussions sur les risques aux moments opportuns.

Les risques que présentent les projets sont habituellement décrits dans les chartes de projets au tout début de chaque projet, mais personne n’est officiellement chargé d’en faire le suivi afin d’assurer une surveillance continue et la mise à jour des stratégies d’atténuation. De nombreuses personnes interrogées ont fait observer que les risques liés aux projets individuels sont étudiés au sein des divers comités et que l’on se sert de son jugement pour déterminer s’il faut soumettre aux échelons supérieurs les risques considérés comme élevés. Les problèmes et les questions soulevés par chaque projet sont traités au niveau du projet au moyen des processus officiels permettant de consigner et de suivre leur évolution. Les risques ne sont pas non plus regroupés et évalués pour l’ensemble du portefeuille des projets. Les comptes rendus de réunions qui ont été examinés ne faisaient pas mention d’une liste regroupant tous les risques liés aux projets, ni de discussions touchant les mesures prises pour atténuer les risques. Aucune liste énumérant tous les risques n’a été fournie. Toutefois, un modèle a récemment été mis au point pour la consignation des risques liés aux projets, mais il n’a pas encore été mis en œuvre.

Recommandation:

6. La direction de l’Agence devrait établir un cadre officiel de gestion des risques liés aux projets afin que ces risques soient régulièrement circonscrits, évalués, traités et surveillés.

Annexe A - Critères de vérification

Les critères de vérification utilisés pour la Phase 1 de la vérification figurent ci-dessous.

Annexe B - Liste des acronymes

Notes

1. Au 31 mars 2006.[Retourne au texte]
2. Renvoi : Tableau de bord pour la direction du Comité de l’IST de l’ASFC, avril 2006 [Retourne au texte]
3. Le Rational Unified Process (RUP) est un processus de développement de logiciel itératif, apparu pour la première fois en 1998. Le RUP est un processus cadre adaptable que les organismes chargés de développer des systèmes peuvent personnaliser pour sélectionner les éléments du processus qui conviennent à leurs besoins. [Retourne au texte]