Affaires étrangères, Commerce et Développement Canada
Symbole du gouvernement du Canada

Affaires étrangères, Commerce et Développement Canada

international.gc.ca

Document archivé

L'information archivée sur le Web est disponible à des fins de consultation, de recherche ou de tenue de dossiers seulement. Elle n’a été ni modifiée ni mise à jour depuis sa date d’archivage. Les pages archivées sur le Web ne sont pas assujetties aux normes Web du gouvernement du Canada. Conformément à la Politique de communication du gouvernement du Canada, vous pouvez obtenir cette information dans un format de rechange en communiquant avec nous.

Vérification de la gestion des projets de technologie de l'information

(Octobre 2004)

Sommaire à l'intention de la direction

Contexte

Le MAECI se distingue en matière d'utilisation des technologies de l'information (TI) puisqu'il se sert principalement d'un réseau mondial pour la collecte et la diffusion de l'information nécessaire à ses programmes et services. Au sein du MAECI, on assiste à une sensibilisation croissante quant à l'importance d'une gestion efficace de l'information et des outils technologiques connexes.

Entre le 1er avril 2001 et le 31 mars 2003, le Ministère a consacré près de 194 millions $ (sans tenir compte des salaires) aux technologies de l'information. Même s'il n'est pas possible d'attribuer exclusivement ces coûts à la gestion des projets visant de nouveaux systèmes ou la mise à niveau de systèmes existants, il est raisonnable de penser que ces chiffres indiquent d'importants investissements du Ministère. Les employés chargés de la gestion de ces investissements, en ce qui a trait aux projets système, sont désormais reconnus comme des intervenants clés, nécessaires à l'atteinte des objectifs de rendement du Ministère.

Pour mieux cerner les préoccupations liées à la gestion des projets TI, la Direction de la vérification (SIV) a procédé à la vérification de douze projets d'une valeur totale de 50 millions $ et dont la réalisation a exigé la participation de 87 personnes et de 42 entrepreneurs.

Les objectifs de cette vérification étaient :

  • Déterminer s'il existe des mécanismes pour s'assurer que les projets TI sont conformes aux objectifs du Ministère;
  • Déterminer si la haute direction a accès à de l'information fiable, lui permettant de prendre des décisions éclairées en ce qui a trait aux projets TI;
  • Déterminer si le MAECI possède une méthode de gestion de projet efficace en ce qui concerne les systèmes;
  • Déterminer s'il existe des pratiques exemplaires et des conditions préalables au succès des projets et en faire la promotion, le cas échéant.

Les critères utilisés par l'équipe de vérification provenaient notamment : du Cadre amélioré de gestion du SCT; du modèle de stabilisation des capacités de l'Institut de génie logiciel; des objectifs de contrôle en technologie de l'information et technologies connexes; des politiques du MAECI en matière d'approbation des projets portant sur la gestion de l'information et de la technologie du cycle de durée des projets du MAECI.

Les résultats de la vérification sont présentés au moyen des catégories suivantes :

  • Fiabilité de l'information pour la prise de décision;
  • Méthodologie;
  • Gestion du risque;
  • Formation.

Les conclusions de la vérification comprennent des recommandations devant permettre d'améliorer les pratiques de gestion de projet TI du Ministère et de faciliter la mise en place de conditions préalables au succès des projets TI. Le rapport commente en outre le besoin d'établir des indicateurs de rendement uniformes pour la gestion des projets TI. De plus, le Ministère doit assurer la « formation pour le succès » en dotant ses gestionnaires de projet des outils de travail appropriés et en s'assurant qu'ils reçoivent la formation nécessaire à l'atteinte des compétences clés exigées par le SCT, avant d'assumer le leadership de projets de plusieurs millions de dollars. Pour appuyer ces projets, le rapport recommande la mise sur pied d'un bureau de gestion de projet (BGP) centralisé sous la gouverne de l'agent d'information en chef (AIC). Le BGP aurait comme objectif de regrouper le personnel expérimenté en matière de gestion de projet dans le but d'aider tous les secteurs quant à l'élaboration des projets TI au sein du Ministère.

Le rapport signale quelques points faibles en ce qui a trait à la fiabilité de l'information transmise à la haute direction pour ce qui est des projets TI et propose des mesures précises pour l'amélioration de la qualité de cette information.

Le rapport indique que SXE a pris des mesures concrètes pour améliorer et développer des outils de travail à l'intention des gestionnaires de projet. Le rapport fait en outre état des pratiques exemplaires observées pendant la vérification et propose de tirer parti des leçons acquises dans le cadre de divers projets bien réussis : SIGBM, COSMOS, ITAMS, EQAMS et GeRC.

L'équipe de vérification a tenté de savoir s'il existe des mécanismes pour s'assurer que les projets TI sont conformes aux objectifs du Ministère, afin d'évaluer « si nous faisons ce qui doit être fait ». Pour répondre à cette question, l'équipe de vérification a passé en revue le nouveau cadre d'établissement des priorités et de planification stratégique ainsi que les résultats servant à mesurer l'atteinte des objectifs. Elle en est venue à la conclusion que les objectifs stratégiques du Ministère correspondaient aux objectifs de chaque projet. En outre, tous les projets comportaient des éléments liés à au moins l'un des objectifs stratégiques du Ministère.

Quoi qu'il en soit, le Ministère ne possède pas de mécanismes de mesure du degré de succès de ces activités car il n'existe pas d'indicateurs standard de rendement des projets au MAECI. Sans de tels critères, même si « nous faisons ce qui doit être fait », il n'est pas possible de savoir jusqu'à quel degré nous faisons ce qui doit être fait, ni avec quel type de succès.

Commentaires de l'AIC

Le rapport de vérification portait principalement sur l'expansion du cadre de gestion de projet (CGP) à l'échelle du Ministère et sur les façons d'assurer un soutien permanent en gestion de projet par le biais du Bureau de gestion de projet (BGP).

Au cours de l'année dernière, SXE a élaboré un CGP standard conforme aux lignes directrices du Secrétariat du Conseil du Trésor et aux pratiques exemplaires de l'industrie. Le CGP sera initialement mis en place au sein de SXD pour en vérifier l'applicabilité et peaufiner les processus avant d'envisager sa mise en place à l'échelle du Ministère.

Les projets TI font actuellement l'objet d'une décentralisation au sein du Ministère. Ainsi, les gestionnaires de programme peuvent et, dans les faits, mettent en oeuvre des projets TI sans consulter l'AIC ni SXD.

En 1997, une ébauche de politique était élaborée (Politique sur les processus d'approbation des projets de gestion de l'information et des technologies de l'information) dans le but d'établir des ligne directrices pour la réalisation des projets GIT au sein du Ministère, mais cette politique n'a jamais été complètement mise en oeuvre.

SXE entend présenter au comité directeur de la GIT une version amendée de cette politique qui comprendrait les processus nécessaires à la prise en charge des projets GIT du Ministère. Cette politique confirmerait en outre le besoin de mettre sur pied un BGP pour la prestation de services standard, comme recommandé dans le rapport de la vérification.

Le CGP élaboré par SXD a déjà reçu des commentaires positifs de la part des groupes TI d'autres ministères; au cours de la journée des solutions générales TI/GI organisée par SXD le 18 juin, au moins cinq ministères ont exprimé leur intérêt quant à l'utilisation du cadre de travail : l'Agence canadienne de développement international (ACDI), le Bureau des passeports, l'Agence des revenus et des douanes Canada, les Services correctionnels du Canada (SCC) et Citoyenneté et Immigration Canada (CIC). Nous avons jusqu'à maintenant rencontré l'ACDI et le Bureau des passeports, et ces deux services ont exprimé un intérêt certain quant à l'utilisation du CGP pour l'établissement d'un groupe de travail visant à améliorer les processus. Cela devrait nous aider à convaincre d'autres directions générales du Ministère des avantages du CGP.

L'équipe de la vérification nous a apporté une aide précieuse pour passer en revue les observations dans le but de nous assurer d'en avoir une compréhension approfondie.

Principaux résultats

  • Les plans de projet TI ne fournissent pas de façon uniforme l'information de base comme l'exigent les normes de gestion de projet de l'AIC. En outre, les plans de projet n'identifient pas les ressources responsables des activités du projet.

Fiabilité de l'information pour la prise de décision

  • Les rapports financiers des projets TI ne fournissent pas d'information fiable quant aux coûts des décisions prises par la haute direction. Le Ministère doit assurer la mise en oeuvre d'éléments de coût destinés à servir de source d'information unique à la haute direction et au système financier du Ministère (SGI).
  • Il n'existe pas de comparaison entre les plans originaux et les plans modifiés des projets; à cet égard, la direction ne sait pas si les ressources évaluées à l'origine servent à l'exécution du projet.
  • Le MAECI n'utilise pas d'indicateurs de rendement standard pour les projets. Pour ces derniers, il faut rédiger un énoncé des critères de succès. Sans de tels critères, même si « nous faisons ce qui doit être fait » dans le cadre des projets, il n'est pas possible de savoir « jusqu'à quel point » nous faisons ce qui doit être fait ni de connaître le degré de succès des projets. De même, sans critère de succès, les gestionnaires de projet ne peuvent démontrer en quoi leur projet a réussi.
  • Les plans de projet ne comportaient aucune stratégie d'approvisionnement, même lorsqu'ils supposaient l'achat de matériel, de logiciel et/ou de services professionnels.

Gestion du risque

  • Les plans de projet déterminent les risques, mais ne documentent aucune stratégie d'atténuation. Par conséquent, la direction n'est pas en mesure de savoir si on a réussi à réduire les risques ou si ces derniers se sont matérialisés, pas plus que de connaître les répercussions qu'ils ont pu avoir sur le projet.

Méthodologie

  • La régie du Ministère en matière d'informatique est considérée comme efficace pour ce qui est du partage de l'information, mais doit être améliorée dans le but de raffermir et d'appuyer la mise en place d'un processus de planification coordonnée pour la gestion de projet et pour l'établissement des priorités TI du Ministère.
  • Il n'existe aucun processus de planification coordonnée au sein du MAECI pour ce qui est de la gestion des projets ni aucun processus formel d'établissement des priorités essentielles en matière de technologie de l'information. Même si on considère de façon positive le rôle du Comité directeur de la GIT en ce qui a trait au partage de l'information entre les principaux intervenants TI, il faudrait qu'un processus structuré soit mis en place pour l'approbation des projets portant sur de nouveaux systèmes.
  • Les normes et les livrables en matière de gestion de projet ne sont pas uniformes à l'échelle du Ministère.
  • L'analyse des plans de projet TI laisse voir que les plans de projet TI du Ministère ne fournissent pas de façon uniforme les données de base exigées par les normes de gestion de projet de l'AIC. Des processus améliorés de production de rapports et de surveillance sont nécessaires dans ce domaine.

Formation

  • Le Ministère doit assurer la « formation pour le succès » en dotant ses gestionnaires de projet des outils de travail appropriés et en s'assurant qu'ils reçoivent la formation nécessaire à l'atteinte des compétences clés exigées par le SCT, avant d'assumer le leadership de projets de plusieurs millions de dollars.

Pratiques exemplaires

  • La vérification a permis de déceler certaines pratiques exemplaires, et le rapport propose certaines histoires à succès, notamment pour ce qui est des systèmes SXEM, SIGBM, COSMOS, ITAMS, EQAMS et GeRC.

Méthode de vérification

Sondage préliminaire

Le sondage préliminaire avait pour but d'acquérir une compréhension globale des projets informatiques en cours au sein du MAECI, d'obtenir des renseignements sur la gouvernance des projets et d'identifier les mesures de rendement pouvant être utiles pour l'analyse comparative des projets du Ministère. Le sondage a également servi à définir les secteurs d'intérêt abordés dans le cadre de la vérification.

Au cours du sondage préliminaire, un questionnaire Web a été diffusé aux gestionnaires de projet dans le but de recueillir l'information de base sur les projets, les pratiques et les normes de rendement.

Travail de terrain

Le travail de terrain a permis une analyse en profondeur des secteurs d'intérêt. L'équipe de vérification a élaboré une liste des projets devant faire partie de la vérification, s'assurant ainsi que les projets échantillonnés comprenaient différents types et tailles de projets TI dans divers secteurs. Les plans, les étapes, le ressourcement, les budgets, les dépenses et les rapports d'état de projet ont été analysés. Les projets vérifiés comprenaient :

Moins de 400 000 $400 000 $ à 2 000 000 $Plus de 2 000 000 $
En coursTerminéEn coursTerminéEn coursTerminé
 EQAMSITAMSMMPRICOSMOS
 ConnexRE, PMMCMSGeRCSIA
  FACDCV  
  • Système de gestion électronique des questions et réponses (EQAMS)
  • Système de gestion des biens liés à la technologie de l'information (ITAMS)
  • Projet de micro-mission (MM)
  • Projet de renouvellement de l'infrastructure (PRI)
  • Système de gestion des opérations consulaires (COSMOS)
  • Gestion immobilière (modules RE, PM SAP)
  • Système de gestion de la correspondance ministérielle (MCMS)
  • Gestion électronique des relations avec la clientèle (GeRC)
  • Système d'intelligence d'affaires (SIA)
  • Faire des affaires avec le Canada (FAC)
  • Délégué commercial virtuel (DCV)

Consultez l'annexe D, Exemples de projets, pour une brève description de chaque projet.

Résultats détaillés

2.0 Fiabilité de l'information pour la prise décision

2.1 Rapports financiers

Les rapports financiers sur les projets TI ne fournissent pas d'information fiable quant aux coûts des projets pour la prise de décisions par la haute direction.

L'équipe de vérification a évalué la pertinence de l'information transmise à la haute direction pour la prise de décisions. Elle a en outre évalué jusqu'à quel point les directeurs recevaient des rapports financiers uniformes, suffisants pour assurer le suivi des progrès pendant la mise en place du système. Compte tenu des renseignements colligés dans le cadre du questionnaire du sondage, il semble que les projets TI du MAECI ne soient pas réalisés dans un cadre standard de budgétisation et d'établissement des coûts. Un processus beaucoup plus uniforme, axé sur une source unique de données financières doit être mis en place.

Aucun des projets vérifiés n'utilisait les rapports du système de gestion intégrée (SGI) pour assurer le suivi des dépenses. On a indiqué à l'équipe de vérification que les données du SGI n'étaient pas suffisamment détaillées pour aider les gestionnaires. Pour répondre à leurs besoins, les gestionnaires établissent leurs propres feuilles de calcul de budgétisation mais, ce faisant, calculent les coûts TI de façon différente. Par exemple, le tableau ci-après comprend les éléments intégrés au budget des divers projets TI.

Tableau des éléments budgétaires

 PSHRMSITAMSEDSSMSSIAPRISGIEQAMSConnexDCVFAC
SalairesX  XX      
Logiciel XXXX X    
Matériel  XXXX     
FormationX XXXXX    
DéplacementsXX  XXX    
Sous-traitance XXXXXXXXXX
Essai    X  X XX
Publication   X       
Rédacteurs techniques X  XX XXX 
Hospitalité           
Hébergement           
Frais de traitementX          
FournituresX          
Traduction        XXX

Il est évident qu'il existe des écarts quant à la compatibilité et à la pertinence des renseignements sur les coûts de projet transmis à la haute direction. Dans certains cas, les gestionnaires de projet qui assurent la saisie complète des coûts de projet peuvent être désavantagés par rapport aux gestionnaires de projet qui sous-estiment les coûts. Les décisions en matière d'affectation des ressources et d'établissement des priorités, notamment les décisions quant à l'approbation du financement d'un projet par la haute direction sont, dans de telles circonstances, loin d'être optimales.

Ces résultats sont corroborés par une étude portant sur la gestion des applications lancée par SXD qui signale que les ressources affectées aux activités de gestion des applications et les coûts attribués aux activités et aux applications n'étaient, dans la plupart des cas, pas accessibles(1).

La question de l'uniformité de la signalisation des coûts de projet a également été indiquée dans le bilan du système relatif aux renseignements commerciaux(2) qui indiquait que le MAECI ne possédait aucun groupe de coordination centrale pour la gestion des hiérarchies de centres financiers (HCF). Plutôt que d'avoir quatre systèmes (SGI, PS, SMS, IA), chacun avec ses propres HCF, le MAECI profiterait beaucoup plus d'un groupe indépendant de coordination centralisée pour assurer l'uniformité des hiérarchies.

Recommandations pour SMSF

2.1.1 SMSF devrait modifier le SGI de façon qu'il soit en mesure de fournir des rapports financiers suffisamment détaillés pour les gestionnaires de projet. (Le SGI devrait au moins être en mesure de fournir des rapports sur les budgets et les coûts réels pour les entrepreneurs, les composantes matérielles, les logiciels, les déplacements, la formation, les salaires, les frais de traitement et les frais juridiques.)

2.1.2 SMSF devrait mettre en place un groupe centralisé pour la gestion des hiérarchies des centres financiers auprès du système de gestion intégrée. Ce groupe ou guichet unique pourrait fournir des détails appropriés de gestion des coûts de projet TI pour toutes les applications.

Recommandation pour l'AIC

2.1.3 L'AIC, de concert avec l'agent financier supérieur, devrait exiger qu'un ensemble uniforme d'éléments de coût soit utilisé pour tous les rapports financiers sur les projets.

Mesures et échéancier

2.1.1 Réponse de SMSF : Il existe différentes possibilités quant aux rapports financiers du SGI proposant suffisamment de détails. Il serait possible de répondre aux besoins des gestionnaires au moyen du module de gestion de projet. Ce module est actuellement utilisé par un petit nombre de personnes de SRD pour la gestion de projets. Il serait également possible d'utiliser des ordres internes ou des centres de coûts du module de contrôle de gestion. SMSF rencontrera les principaux intervenants pour passer en revue leurs besoins en matière de rapports financiers et déterminer quelles fonctions pourraient le mieux y répondre. Il serait ensuite possible d'évaluer les efforts nécessaires à la mise en oeuvre de ces fonctions.

Échéancier : En cours

2.1.2 Réponse de SMSF : L'établissement d'un nouveau centre financier comporte deux étapes : obtention de l'approbation de la part de la Direction de planification stratégique et des ressources humaines (HRP) pour ce qui est de la création d'une nouvelle unité structurelle et obtention de l'approbation de SMSF pour l'établissement d'un nouveau centre financier dans le SGI. Les groupes responsables du SGI, du SMS, du SGRH et de l'IA ont dernièrement rencontré HRP pour confirmer le processus de gestion nécessaire à la création d'un nouveau centre financier et pour faire des recommandations afin que l'information établie dans chaque système pour les nouveaux centres financiers soit uniforme. Comme indiqué dans la recommandation 2.1.1., les gestionnaires de projet TI devraient utiliser le module de système de projet ou le module de contrôle pour assurer la gestion et le suivi de leurs coûts de projet TI.

Échéancier : En cours

2.1.3 Réponse de l'AIC : Le nouveau CGP (voir 2.2.1) comprend déjà des modèles d'établissement des coûts qui définissent des éléments de coût uniformes. Cet élément sera peaufiné avec l'agent financier supérieur. Le système de production de rapports sur les projets est également en cours d'amélioration et la mise en place d'une application améliorée d'établissement des coûts de projet fait partie du processus.

Échéancier : Terminé

2.2 Ressourcement des projets

Les évaluations en matière de ressources pour les projets TI dépendent des activités demandées, des délais imposés et des ressources accessibles. Toutefois, les données estimatives de base ne sont pas comparées avec les ressources réellement utilisées.

L'affectation de ressources aux activités assure l'imputabilité tout au long du projet quant à l'exécution des activités et à l'atteinte des résultats souhaités. Les personnes affectées doivent posséder une autorité suffisante pour assumer les responsabilités qui leur sont attribuées. Le modèle de stabilisation des capacités logicielles CMMI de l'Institut de génie logiciel précise que le gestionnaire de projet doit attribuer la responsabilité et les autorisations d'exécution des processus, d'élaboration des produits et de la prestation des services exigés pour le processus.(3)

Les ressources utilisées dans le cadre des projets TI ayant fait l'objet de l'analyse dépendaient des compétences accessibles en fonction des activités. Les évaluations globales faisaient partie des analyses de rentabilisation ou documents de lancement du projet. Des modifications à ces données estimatives ont été apportées à mesure que le projet progressait et que les ressources étaient disponibles.

Le modèle CMMI(4) exige du gestionnaire de projet qu'il assure la vérification des valeurs réelles des paramètres de planification par rapport aux valeurs initiales du plan, tout particulièrement en ce qui a trait aux ressources fournies et utilisées.

Dans les projets analysés, on a noté que les ressources étaient inscrites au plan des projets vis-à-vis des activités dont elles étaient responsables. Cependant, il n'y avait aucun suivi du temps réellement consacré aux activités du plan et, par conséquent, les gestionnaires de projet connaissaient rarement la précision de leur budget quant aux travaux prévus.

Par exemple, les lacunes suivantes ont souvent été observées dans différents projets vérifiés :

  • Aucune évaluation des efforts exigés à l'échelle du plan.
  • Le plan n'indique pas si les activités et les frais de ressourcement correspondaient aux données planifiées.
  • La durée réelle d'exécution du projet n'était pas indiquée et le plan ne précisait pas si l'activité avait été exécutée à temps ou non.
  • Pour ce qui est des équipes de projet comprenant des employés du MAECI, les données estimatives étaient définies par l'équipe de projet et intégrées au plan. Il n'était pas possible de déterminer si les activités avaient été réalisées dans le respect du budget, puisqu'il n'y avait aucun plan de projet de base défini.

En l'absence de critères de succès, les gestionnaires de projet ne peuvent démontrer de façon objective les succès atteints. Le Ministère doit adopter et mettre en place des mesures qui appuient et vérifient les succès obtenus par les gestionnaires de projet. Les exemples dont il faudrait tenir compte comprenaient les pratiques exemplaires suivantes :

  • Le projet COSMOS.NET a fait appel à des entrepreneurs dont le contrat définissait les livrables souhaités. Les entrepreneurs se sont engagés à livrer le produit moyennant un coût fixe, et par conséquent la Direction générale des affaires consulaires ne courait aucun risque de voir augmenter ces coûts.
  • La mise en place du délégué commercial virtuel (DCV) a également été confiée à la sous-traitance. L'entrepreneur devait établir un plan détaillé du projet au moyen du logiciel Microsoft Project, qui comprenait :
    • Activités, étapes et chemins critiques;
    • Effort nécessaire à la réalisation de chaque activité;
    • Ressources nécessaires à la réalisation de chaque activité.

L'entrepreneur devait se servir du plan du projet de base et y faire référence pour comparer toute modification au plan.

Les projets COSMOS.NET et DCV reposaient sur des contrats qui facilitaient l'accès aux ressources, au moment opportun. D'autres projets TI font appel à des offres permanentes qui facilitent l'obtention rapide des ressources nécessaires. Des tâches précisent ont été attribuées aux entrepreneurs, qui devaient fournir des délais et des efforts estimatifs. Une fois ces données estimatives approuvées, l'entrepreneur était responsable de la réalisation des activités, au besoin. Comme les entrepreneurs assuraient la réalisation des travaux à coût fixe, il n'y avait aucun risque de frais supplémentaires.

Le mandat du projet ITAMS comportait une stratégie de ressourcement pour le soutien permanent de l'application après sa mise en oeuvre(5). C'est le seul exemple observé de planification du soutien d'une application dans le cadre de la planification de projet TI.

Recommandations pour SXEM

2.2.1 SXEM devrait modifier les normes de gestion de projet du MAECI afin d'y intégrer une disposition prévoyant la nomination de membres précis de l'équipe dU projet à titre de responsables de chaque activité.

2.2.2 Les besoins de SXEM en matière de production de rapports devraient comprendre la durée des activités, les travaux requis et un indicateur précisant si l'utilisation des ressources est supérieure, inférieure ou conforme aux prévisions.

Mesures et échéanciers

2.2.1 SXEM a élaboré un cadre de gestion de projet (CGP) standard en fonction des lignes directrices du Secrétariat du Conseil du Trésor et des pratiques exemplaires de l'industrie. SXD procède à l'élaboration de ce CGP dans le but d'en vérifier l'applicabilité et de peaufiner les processus avant de le diffuser à l'échelle du Ministère. MS Project est la norme de facto en matière de planification de projet et propose des fonctions d'enregistrement des noms des membres de l'équipe responsables de chaque activité.

Échéancier : Terminé

2.2.2 Des exigences en matière de production de rapports sur les projets sont établies pour aviser le Comité de gestion de la Direction générale SXD des projets devant faire l'objet d'un suivi. SXEM étudie actuellement la possibilité d'utiliser MS Project Server 2003 qui fournit des rapports sur les projets généraux et permet l'intégration des données de projet suffisamment détaillées en fonction des échelons de gestion. (Voir 2.4.2.) Entre-temps, SXEM évaluera les répercussions que pourrait avoir l'ajout de l'information recommandée aux outils de production de rapports existants.

Échéancier : Automne

2.3 Planification de l'approvisionnement

Les plans de projet analysés ne comportaient aucune stratégie ni activité d'approvisionnement.

Des études effectuées par le vérificateur général(6) ont démontré que le fait de ne pas tenir compte du temps nécessaire aux activités d'approvisionnement lors de la phase « achat » d'un projet TI et des activités d'approvisionnement connexes constituait l'un des facteurs à l'origine du non-respect des délais de réalisation des projets TI. De plus, l'analyse ministérielle dans le cadre de la modernisation de l'acquisition des services professionnels (mai 2002) indique qu'il existe un consensus général voulant que les importants problèmes de délai soient attribuables à l'absence de planification formelle des projets et de l'approvisionnement(7). Cette analyse a également démontré que le processus d'approvisionnement est rarement considéré comme un élément essentiel des plans de mise en oeuvre.

Le cadre amélioré de la gestion (CAG) mis au point pour la gestion des projets de technologie de l'information est conçu pour faire en sorte que les projets TI du gouvernement répondent parfaitement aux besoins pour lesquels ils sont élaborés, donnent tous les avantages prévus et soient exécutés dans le respect des délais, des coûts et des ressources établis. Il comporte des pratiques exemplaires, des principes, des méthodes, des outils et des normes déterminés dans le cadre d'un projet interministériel et destinés à fournir des solutions aux problèmes de gestion de projet rencontrés par le gouvernement fédéral.

  • Le site Web ci-après fournit les solutions CAG du SCT définies, accompagnées du plateau de mise en oeuvre approprié. Lorsqu'une solution ou un outil est utilisé, on s'attend à ce que cette utilisation soit peaufinée et se poursuive à tous les échelons (http://www.cio-dpi.gc.ca/emf-cag/about/abu-ans04_f.asp).
  • Plateau 0 : Référentiel : Ce plateau vise à garantir que les ministères possèdent les solutions de base nécessaires à l'établissement et à la gestion d'un projet, notamment : analyse de rentabilisation, stratégie d'approvisionnement, mandat de projet, processus d'analyse et de déclenchement; mécanismes de contrôle et de planification; méthode de gestion du risque.
  • Plateau 1 : Niveau du projet : Ce plateau a pour objectif d'assurer la planification appropriée des projets du MAECI et de donner suffisamment de visibilité aux progrès dans le but de permettre à la haute direction de prendre les mesures nécessaires lorsque le projet s'éloigne du plan tracé. C'est également sur le plateau 1 que les mesures sont prises pour s'assurer que les gestionnaires de projet possèdent les connaissances, l'expérience et les outils nécessaires à leurs besoins et à l'exécution du projet.
  • Plateau 2 : Niveau des produits : Ce plateau tente d'établir, à l'échelle du projet, des processus et des mesures de contrôle efficaces et uniformes pour ce qui est de la gestion du changement, de l'intégrité et de la qualité du produit.
  • Plateau 3 : Niveau de l'organisation : Le troisième plateau porte essentiellement sur l'uniformité et a pour objet de faire en sorte que les meilleurs processus intégrés au projet à l'échelle d'un ministère sont également transmis aux autres projets de ce groupe.
  • Plateau 4 : Amélioration continue : Le dernier plateau porte sur l'amélioration de l'efficacité organisationnelle du MAECI sur une base permanente (par exemple pour livrer de meilleurs projets, plus rapidement et à moindre coût). Ce plateau comprend des techniques quantitatives de mesure des processus et des activités proactives destinées à rationaliser et améliorer les pratiques existantes et les autres pratiques exemplaires.

Les principes du CAG(8) décrivent le rôle de TPSGC, qui consiste à établir des plans ainsi que des conditions et des modalités de marché qui répondent aux besoins d'un projet TI et à la mise en application d'un cadre amélioré de la gestion. Les principes du CAG indiquent en outre que la fonction d'approvisionnement au sein du gouvernement est très complexe parce qu'elle est articulée autour d'une réglementation conçue pour donner à toutes les entreprises admissibles un accès égal aux marchés gouvernementaux. Par conséquent, les gestionnaires de l'approvisionnement doivent participer aux toutes premières étapes de tous les projets. Cela leur permet d'établir un processus d'approvisionnement qui réduit les délais et qui harmonise le plan des marchés au niveau du projet tout en respectant les exigences législatives, politiques et protocolaires; ce processus harmonise en outre les éléments du contrat avec les avantages définis dans le cadre du projet.

Les normes de gestion de projet de l'AIC et de SXEM exigent l'élaboration d'un plan d'approvisionnement pour tous les projets TI de grande envergure. Ce plan définit et assure le suivi des mesures nécessaires à l'achat des biens et/ou des services. Il doit être élaboré aux toutes premières étapes du cycle de vie du projet pour donner suffisamment de temps à l'exécution des activités d'approvisionnement et faciliter la planification du projet. Aucun des projets de grande envergure analysés ne comprenait de documentation indiquant qu'une stratégie et un plan d'approvisionnement avaient été élaborés. De concert avec les spécialistes en approvisionnement et en marché du MAECI, un modèle de processus et des exigences générales relatives aux marchés ont été élaborés et présentés dans l'annexe E.

Dans les projets analysés, trois méthodes étaient utilisées pour l'acquisition du matériel, du logiciel ou des sous-traitants. L'une des méthodes supposait un contact direct avec TPSGC pour la publication d'une demande de propositions (DP) sur MERX et la sollicitation de la proposition la plus économique pour la prestation de services ou la fourniture de marchandises. La seconde méthode faisait appel au personnel de l'approvisionnement du MAECI pour assurer la liaison avec TPSGC lors de la publication d'une DP. La troisième méthode portait sur l'utilisation d'une offre permanente pour l'obtention de services. Dans deux des projets TI pour lesquels on avait fait directement affaire avec TPSGC, le personnel a été extrêmement satisfait des résultats, aucun délai d'importance n'ayant découlé du recours à ce type d'approvisionnement.

Dans un autre projet, une DP a été publiée sur MERX pendant 20 jours. Puis, à la demande du fournisseur, la publication a été prolongée de 20 jours supplémentaires. Par conséquent, le projet a subi un délai d'un mois par rapport au plan original. Le mandat du projet indique l'achat de logiciels standard, sans toutefois faire mention d'un risque lié à l'approvisionnement. Toutefois, en raison des préoccupations du SCT quant à la possibilité de ne pas recourir à un système partagé, la DP a été retardée une fois de plus. Ces préoccupations auraient dû être résolues avant de publier la DP dans MERX.

Dans un autre projet, le plan comprenait une activité « d'acquisition de nouveaux serveurs » sans cependant préciser le délai nécessaire à l'achat qui, dans ce cas précis, a exigé quatre mois.

Pratique exemplaire

Recommandations pour SXEM

2.3.1 SXEM, de concert avec l'AIC, doit mettre à jour les normes de gestion de projet du MAECI pour faire en sorte que des plans d'approvisionnement soient intégrés aux risques du projet et à titre d'activité du plan de projet.

2.3.2 SXEM, de concert avec l'AIC, doit concevoir et diffuser un modèle de plan de projet qui appuie l'élaboration des plans comprenant tous les livrables souhaités. (Le modèle doit être conçu de façon que tous les projets de même envergure utilisent le même format de plan de projet.)

Mesures et échéancier

2.3.1 Ce commentaire était valable au moment de la vérification, mais le cadre de gestion de projet a été mis à jour depuis. Il existe maintenant un modèle de plan d'approvisionnement intégré au cadre de gestion de projet.

Échéancier : terminé

2.3.2 Ce commentaire était valable au moment de la vérification, mais le cadre de gestion de projet a été mis à jour depuis. SXEM recommande un modèle de plan de projet pour chacune des trois tailles de projet. SXEM fournit en outre des exemples de différents types de projets, notamment pour la mise en oeuvre d'infrastructure, la programmation d'application, etc., afin d'aider les gestionnaires de projet.

Échéancier : Terminé

2.4 Surveillance et contrôle de projet

Aucun indicateur standard de rendement de projet n'est utilisé au MAECI.

Toute méthode efficace de gestion du rendement utilise des indicateurs pour encourager la mise au point de mesures d'amélioration du rendement. Les mesures et les données de rendement doivent être liées aux processus de gestion stratégique(10).

Tout système efficace de gestion du rendement produit de l'information qui donne les avantages suivants :

  • Signale rapidement les risques de problèmes et propose des mesures de correction efficaces;
  • Fournit des renseignements quant à la planification et l'affectation des ressources. Peut aider le MAECI à se préparer aux conditions à venir, pouvant avoir des répercussions sur le programme ou les fonctions de soutien tout en prévoyant les demandes de produits et services pouvant découler de la réduction du personnel, de la réduction des ressources financières ou de la modification de la charge de travail. Le recours à de telles mesures pourrait permettre au MAECI d'avoir suffisamment de temps pour s'ajuster aux demandes, tout particulièrement lorsque les conditions sont connues à l'avance;
  • Fournit des commentaires périodiques aux employés, aux intervenants et au public en général quant à la qualité, à la quantité, au coût et à la livraison en temps voulu des produits et services.

Tableau de bord de direction

Comme indiqué, le cadre amélioré de gestion du Conseil du Trésor pour les projets TI prévoit le recours à un « tableau de bord de direction »(11) pour donner en un clin d'oeil à la haute direction une vue d'ensemble de la santé d'un projet TI.

Le tableau de bord de la direction fournit rapidement de l'information sur l'état du projet et sur les principaux points d'intérêt essentiels. Le tableau de bord permet de mesurer rapidement l'état des projets TI.

Recommandations pour SXEM et l'AIC

2.4.1 Les normes de gestion de projet de SXEM et de l'AIC doivent être mises à jour pour tenir compte des directives en matière de mesures du rendement des projets TI. L'étendue et le type de mesure, ainsi que les rapports qui y correspondent, doivent tenir compte de la taille du projet.

2.4.2 Les normes de gestion de projet doivent adopter des rapports de type « tableau de bord de direction » du Conseil du Trésor pour la production des rapports à l'intention de la haute direction du MAECI.

Mesures et échéancier

2.4.1 Les normes de gestion de projet SXD seront mises à jour pour assurer la gestion du rendement des projets TI, pour les trois envergures de projets.

Échéancier : Au cours de l'exercice

2.4.2 SXEM a réalisé au cours de l'exercice précédent un projet d'élaboration de tableau de bord de direction. En raison des restrictions budgétaires liées à l'achat du logiciel MS Project Server 2003 pour la production des rapports ministériels, le projet a été reporté.

Échéancier : À déterminer

3.0 Méthodologie

3.1 Structure de gouvernance

La régie du Ministère en matière d'informatique est considérée comme efficace pour ce qui est du partage de l'information, mais doit être améliorée dans le but de raffermir et d'appuyer la mise en place d'un processus de planification coordonnée pour la gestion de projet(12) et pour l'établissement des priorités TI du Ministère(13).

La gouvernance TI propose la structure qui établit des liens entre les processus TI, les ressources TI, l'information et les stratégies et objectifs du MAECI. De plus, la gouvernance TI intègre et institutionnalise de bonnes pratiques (ou des pratiques exemplaires) pour la planification, l'organisation, l'acquisition, la mise en oeuvre, la livraison, le soutien et la surveillance du rendement TI afin de faire en sorte que l'information et les technologies connexes du MAECI appuient les objectifs du Ministère. Par conséquent, la gouvernance TI permet au MAECI de tirer pleinement avantage de l'information, maximisant ainsi les bénéfices et tirant profit des possibilités.

En 1996, le Ministère réorganisait la GIT, et la haute direction mettait sur pied le Comité directeur de la GIT pour coordonner toutes les activités GIT du Ministère. Un agent d'information en chef (AIC) a été nommé et participe dorénavant à toutes les discussions du Comité exécutif du Ministère qui portent sur les GIT. L'AIC dirige le Comité directeur de la GIT ainsi que le forum des opérations GIT. Il élabore en outre les mécanismes nécessaires à l'harmonisation de l'orientation et des investissements GIT avec les objectifs du Ministère.

La structure de gouvernance des projets TI définis par l'AIC est la suivante :

Régie GIT

La structure de gouvernance élaborée par l'AIC pour le Ministère diffère de celle définie pour certains projets TI d'envergure. Deux des projets ne comportaient aucun lien entre la structure de gouvernance de projet et le Comité directeur de la GIT, pas plus qu'avec les autres comités de gouvernance mis sur pied par l'AIC. Il n'existait aucune preuve de l'approbation de ces projets par le Comité directeur de la GIT, comme l'exigent les normes du MAECI.

À l'opposé, le mandat du projet ITAMS comportait un excellent diagramme de gouvernance du projet et de l'organisation. Le mandat précisait que l'AIC était le promoteur exécutif tandis que le directeur du projet était le directeur de la gestion des affaires SXM. Le projet comportait de nombreux comités, chacun possédant des responsabilités précises décrites dans le mandat du projet.

Pratiques exemplaires

  • Les activités de gouvernance TI sont intégrées aux processus de gouvernance et au leadership directorial du MAECI puisque l'AIC est responsable de l'élaboration des mécanismes d'harmonisation de l'orientation et des investissements GIT avec les objectifs du Ministère.
  • La gouvernance TI insiste sur les objectifs et les initiatives stratégiques du MAECI, sur le recours à la technologie pour améliorer les opérations et sur la disponibilité de ressources et capacités suffisantes pour répondre aux demandes du Ministère en exigeant de l'AIC qu'il fasse rapport au comité exécutif.

Recommandations pour l'AIC

3.1.1 L'AIC doit établir un bureau de gestion des projets chargé de voir à ce que tous les projets TI respectent la structure de gouvernance et les exigences de production de rapports du Ministère.

3.1.2 Le bureau de gestion des projets doit jouer le rôle d'un centre d'excellence en matière de gestion de projet au MAECI en fournissant (ou en participant au recrutement) des directeurs de projet qualifiés (y compris des consultants) pour les projets TI, au besoin, et en conservant une base de données de plans de projet.

3.1.3 Le bureau de gestion des projets doit proposer un ensemble de méthodes et d'outils de réalisation de projet et doit conserver des composantes réutilisables (par exemple modèles de plans de projet, modèles d'établissement des coûts, etc.).

3.1.4 Le bureau de gestion des projets relève du Comité exécutif, par le biais de l'AIC, en ce qui concerne l'atteinte des objectifs des projets TI.

Mesures et échéancier

3.1.1 Comme les projets TI sont décentralisés à l'échelle du Ministère, les gestionnaires de programmes peuvent lancer et, dans les faits, lancent leurs propres projets TI sans consulter SXD ni l'AIC. La politique existante sur le processus d'approbation des projets de gestion de l'information et des technologies de l'information (14 novembre 1997) n'est pas totalement mise en oeuvre. Le bureau de l'AIC analysera la politique et y intégrera les recommandations de la vérification. L'AIC présentera ensuite la politique révisée au comité directeur de la GIT pour approbation.

Échéancier : Hiver 2004/2005

SXD a mis sur pied un bureau de gestion des projets (SXEM) pour la Direction générale SXD. Dès que l'utilité du CGP aura été prouvée au sein du bureau, l'AIC proposera d'en faire une norme pour le Ministère.

Échéancier : À déterminer

3.1.2 La mise en place au sein du Ministère d'un bureau de gestion des projets comme décrit précédemment dépend de l'approbation par le comité directeur de la GIT de la politique révisée sur le « processus d'approbation des projets de gestion de l'information et des technologies de l'information ». Si le bureau de gestion des projets devait être mis en place, il faudrait d'une part y recourir pour tous les projets et d'autre part, il devrait être suffisamment financé, au moyen d'une structure de récupération des coûts ou par l'attribution de crédits directs du Ministère. Les restrictions budgétaires touchant les nouveaux projets devront aussi être prises en compte.

Échéancier : À déterminer

3.1.3 SXD possède un ensemble d'outils uniformes ainsi qu'un cadre de gestion de projet (CGP) comportant des modèles et des gabarits. L'AIC procédera à leur diffusion à l'échelle du Ministère dès que nous serons certains que le CGP est prêt.

Échéancier : À déterminer

3.1.4 La mise en place d'un bureau de gestion des projets à l'échelle du Ministère, relevant de l'AIC pour tous les projets GIT, exigerait la délégation de pouvoirs accrus à l'AIC de la part du comité exécutif.

Échéancier : À déterminer

3.2 Processus d'approbation des projets

Un processus d'approbation des projets est en place. Toutefois, il n'existe aucune preuve du recours au processus d'approbation établi par le Comité directeur de la GIT pour l'approbation des projets dont le comité était responsable pas plus qu'il n'existe de critères documentés pour l'approbation de ces projets.

Le Comité directeur de la GIT doit se concentrer sur les questions liées au leadership opérationnel des opérations GIT du Ministère : planification, politique, gestion, production des rapports, établissement des priorités en matière d'investissements, communications et formation. Il approuve les plans stratégiques GIT, les politiques, les projets de moyenne et de grande envergures, les risques et les répercussions opérationnelles.

Un processus d'approbation des projets(14) a été élaboré et comprend les éléments suivants :

1. Tout projet GIT proposé dont le coût total (immobilisations plus exploitation sur cinq ans) est évalué à 200 000 $ ou plus, ou dont les risques et/ou les répercussions sont jugés comme étant « moyens » ou « élevés » doit être approuvé par le Ministère.

2. Les propositions de tels projets doivent être transmises au Comité directeur de la GIT par le bureau de l'AIC. Le comité directeur peut approuver ces propositions, les rejeter ou encore les approuver sous réserve des conditions qu'il juge appropriées.

3. L'approbation complète de ces projets accorde l'autorisation de procéder à la réalisation du projet sous réserve de l'absence de changement substantiel du budget, des fonctions, de la technologie ou des objectifs ministériels pouvant modifier les raisons en vertu desquelles l'approbation a été accordée et, par conséquent, pouvant justifier une nouvelle demande d'approbation (tous les projets approuvés exigent la production de rapports de progrès annuels qui permettent à l'AIC de déceler de tels changements, ainsi qu'un rapport de réalisation de projet).

L'AIC exerce son autorité seulement sur recommandation du Comité directeur de la GIT pour les nouveaux projets dont le coût total est de 400 000 $ ou plus ou pour les projets de remplacement dont le coût total est de 1 000 000 $ ou plus. Les projets de valeur inférieure peuvent être approuvés par l'AIC, sans consultation du Comité directeur de la GIT, à moins qu'il ne considère que les risques et/ou les répercussions soient suffisamment élevés pour justifier l'approbation du Comité directeur de la GIT.

Les responsabilités de l'AIC comprennent(15) :

  • Élaboration de la politique stratégique et établissement des priorités et des programmes GIT du Ministère;
  • Consolidation des plans et des budgets pour toutes les dépenses GIT du Ministère;
  • Mise en place d'un cadre de gouvernance GIT, y compris la présidence du comité directeur de la GIT et du groupe des propriétaires des grandes applications, et soutien global à la structure de gouvernance;
  • Mise en place de mécanismes pour assurer l'harmonisation de l'orientation et des investissements GIT avec les objectifs du Ministère;
  • Mise en place d'indicateurs du rendement GIT pour mesurer le rendement des investissements GIT.

Au cours de la vérification, on a procédé à une analyse des fichiers des projets et des procès-verbaux du Comité directeur de la GIT. L'équipe de vérification n'a trouvé aucune preuve de l'utilisation du processus d'approbation mis sur pied par le Comité directeur de la GIT pour l'approbation des projets. Le principe 4.2.1 du CAG du SCT stipule : « Les projets TI doivent être harmonisés avec les orientations et les priorités du Ministère et doivent en assurer le soutien.»(16) Cela suppose une analyse complète de rentabilisation pour s'assurer que l'approbation repose sur l'analyse de rentabilisation qui doit établir des liens directs entre l'investissement et la fonction à mettre en place. L'analyse de rentabilisation doit en outre faire la démonstration des avantages de l'investissement pour le MAECI ou pour le gouvernement, en plus de définir les besoins ministériels.

Recommandation pour l'AIC

3.2.1 Le DPI, en tant que président du Comité directeur de la GIT, doit s'assurer que les procès-verbaux des rencontres du Comité directeur de la GIT documentent clairement les projets TI dont on demande l'approbation, les projets TI approuvés par le Comité directeur et tout projet rejeté. Le justificatif de toutes les décisions doit faire partie du procès-verbal du Comité directeur de la GIT.

Mesures et échéancier

3.2.1 Les procès-verbaux du Comité directeur de la GIT documentent actuellement les demandes d'approbation ainsi que les approbations et les rejets. Cependant, tous les projets ne sont pas nécessairement soumis pour approbation au Comité directeur de la GIT. Des efforts seront faits pour s'assurer que tous les projets proposés sont portés à l'attention du Comité directeur de la GIT, et que ce dernier réaffirme son rôle à titre d'organisme décisionnel en la matière.

Échéancier : Permanent

3.3 Normes des projets TI

L'AIC a élaboré des normes de gestion de projet pour le Ministère. SXEM a aussi élaboré des normes de gestion de projet pour le Ministère, mais il existe des écarts entre ces normes. En outre, en dépit des normes, les projets ne donnent pas les livrables conformes aux exigences.

Les normes de projets TI de l'AIC établissent trois phases dans le cycle de vie d'un projet.

Phase 1 La mise en marche du projet débute par la conception de l'idée et prend fin par l'élaboration et l'évaluation de l'analyse de rentabilisation.

Phase 2 Pendant la réalisation du projet, les activités nécessaires à la réalisation du projet sont exécutées, vérifiées et mesurées.

Phase 3 La phase de clôture et de récapitulation du projet comprend l'évaluation des aspects positifs du projet ainsi que la détermination des possibilités d'amélioration, l'identification des « pratiques exemplaires » pouvant être intégrées aux projets à venir et l'évaluation du rendement des membres de l'équipe du projet.

SXEM a intégré un ensemble de modèles de planification de projet à son site intranet. Ces modèles sont articulés autour du cycle de vie de projet défini par l'AIC, mais les modèles SXEM diffèrent des modèles de l'AIC. À titre d'exemple, le site Web de SXEM propose trois documents pour la mise en marche du projet : formulaire de mise en marche du projet; analyse de rentabilisation; questionnaire d'évaluation des répercussions. L'AIC propose : analyse de la rentabilisation, sommaire de projet, charte de projet, exigences caractéristiques et plan de projet.

Même si la majorité des livrables de la norme de l'AIC et de la norme SXEM sont identiques, il existe un certain nombre de différences entre les deux normes :

LivrableDPISXEMSCT
Phase 1 - Planification/mise en marche
Analyse de rentabilisationOOO
Charte de projetO  
Chartede projetOOO
Exigences caractéristiquesOOO
Plan de projetOOO
Mise en marche du projet O 
Évaluation des répercussions O 
Évaluation des risques et des menaces O 
Énoncé de sensibilité O 
Risque O 
Plan de communication OO
Phase 2 - Réalisation
Conception du systèmeOO 
Plan d'essaiOO 
Plan d'assurance qualitéO O
Plan de gestion des risquesOOO
Plan de gestion d'étapeOO 
Mesures du projetOO 
Mesure du rendementOOO
Plan de communicationO O
Plan d'acceptationO  
Plan de formationO  
Phase 3 - Clôture du projet
Plan de remise O&MOOO(17)
Plan de continuité des affairesOO 
Évaluation du rendement/ leçonsOO 
Clôture du projetOO 

SXEM a également établi d'autres normes de gestion de projet sous la gouverne de SXD. Ces normes semblent plus souples que les normes actuelles et définissent les livrables en fonction de la taille du projet. Les normes proposées définissent ainsi les projets : projets de petite envergure - budget de moins de 100 000 $ exigeant jusqu'à trois personnes; durée estimative : moins de six mois; projets de moyenne envergure - budget variant de 100 000 $ à 500 000 $ et exigeant de six à dix personnes; durée estimative : 12 à 18 mois; projets de grande envergure - budget de 500 000 $ ou plus, exigeant au moins dix personnes; durée estimative supérieure à 18 mois.

Ces définitions diffèrent de celles de l'AIC pour ce qui est des projets de petite, moyenne et grande envergure. La politique sur l'approbation des projets GIT(18) définit les petits, moyens et grands projets strictement sur la base des budgets approuvés. Ainsi, un petit projet peut avoir un budget de moins de 400 000 $, un projet moyen, un budget de moins de 2 000 000 $ et un grand projet, un budget de plus de 2 000 000 $, qui exige alors l'approbation du Conseil du Trésor.

En outre, les normes de l'AIC ne font aucune différence quant aux livrables exigés pour les petits, moyens et grands projets, alors que les normes proposés par SXEM établissent des différences en matière de livrables en fonction de la taille du projet. Les normes proposées par SXEM(19) se trouvent à l'annexe A. (Note : Ces normes font l 'objet de révision et la version fournie était à jour au moment de vérification.)

Le Conseil du Trésor possède également des exigences en matière de livrables, définies dans le Guide de gestion de projet. Ce guide est articulé autour des pratiques exemplaires de l'industrie, appuyées des leçons tirées des projets GI/TI du Gouvernement du Canada. Pour plus de détails, consultez l'adresse http://www.cio-dpi.gc.ca/emf-cag/pmg-ggp/intro/intro_f.asp. Ce document intègre les principes du Guide du référentiel des connaissances en gestion de projet du Project Management Institute (PMBOK), qui eux-mêmes sont axés sur les processus afférents au cycle de vie des logiciels de l'Organisation de normalisation internationale (ISO/IEC 12207) et appuient les principes du modèle de stabilisation de capacité (CMM) de l'Institut de génie logiciel et d'autres documents de référence externes ou du Secrétariat du Conseil du Trésor (SCT).

L'analyse des livrables attribuables aux projets faisant l'objet de la vérification laisse entrevoir de nombreuses différences entre les livrables. Ainsi, tous les projets n'ont pas donné les livrables exigés par les normes de gestion de projet de l'AIC. Et quand les livrables étaient produits, leur contenu ne s'avérait pas uniforme et n'était pas conforme au format prescrit pour les normes de gestion de projet de l'AIC.

Seulement cinq projets comprenaient un plan de projet, et ces plans différaient grandement quant au degré de détails fournis. Seulement cinq projets comportaient un plan de gestion du risque et, là encore, ces plans variaient quant aux détails fournis. L'approbation de sept des projets reposait sur de la documentation de lancement, et seulement six projets comportaient des définitions d'exigences caractéristiques. Les lacunes quant à ces définitions sont importantes, puisqu'elles décrivent les besoins opérationnels auxquels l'application est appelée à répondre. Il s'agit des besoins pour lesquels l'application doit être conçue.

Recommandation pour l'AIC

3.3.1 L'AIC doit établir un seul ensemble de normes de gestion de projet pour le MAECI, intégrant des mesures uniformes pour l'établissement de la taille d'un projet. Ces normes doivent prévoir des différences en matière de taille et de risque des projets.

Recommandation pour SXEM

3.3.2 Le bureau de gestion des projets mis en place doit mettre un oeuvre un processus de révision pour s'assurer que tous les projets TI donnent les livrables requis en fonction du type et de la taille du projet.

Mesures et échéancier

3.3.1 Des normes de projet ont été définies pour SXD. Ces définitions font partie du cadre de gestion de projet, actuellement à l'essai au sein de SXD. Dès que ce cadre aura été peaufiné, il sera présenté à l'AIC pour mise en oeuvre à l'échelle du Ministère.

Échéancier : À déterminer

3.3.2 Trois types de projets ont été définis en fonction de la taille, du budget et des répercussions. Chaque type comprend un ensemble d'exigences en matière de production de rapports quant aux livrables requis. Ce cadre de gestion de projet est actuellement en cours d'essai à SXD.

Échéancier : En cours

3.4 Planification

L'analyse des plans des projets TI indique que les plans TI du Ministère ne fournissent pas de façon uniforme l'information de base exigée conformément aux normes de gestion de projet de l'AIC. Même si tous les plans de projet comprennent des dates d'exécution des activités et des étapes, ils ne précisent pas toujours les personnes responsables de ces activités.

L'équipe de vérification a analysé un échantillon de huit plans de projet TI; elle en est venue à la conclusion qu'aucun de ces plans ne comprenait les renseignements exigés en fonction des normes des plans de projet de l'AIC. On s'est en outre aperçu qu'il n'existait aucune uniformité entre les plans. Par exemple, tous les plans de projet TI comprenaient des dates de début et de fin d'activités (tâches), cependant, seulement trois de ces plans précisaient les personnes responsables de chaque activité.

En outre, certains des plans de projet ne déterminaient pas les tâches nécessaires à l'obtention des livrables exigés par les normes de gestion de projet de l'AIC.

Recommandation pour SXEM

3.4.1 SXEM, de concert avec le groupe des propriétaires des grandes applications doit s'assurer que tous les plans de projet TI définissent clairement les activités exigées par les normes de gestion de projet du Ministère. Ces plans doivent notamment comprendre les renseignements suivants, sans toutefois s'y limiter :

  • Personnes responsables de chaque activité du projet;
  • Dates butoirs pour la diffusion :
    • Des plans d'assurance de la qualité;
    • Des plans d'essai;
    • Des plans de gestion du risque;
    • Des plans de formation des utilisateurs;
    • Des travaux exigés pour chaque activité;
    • Du budget de chaque activité.

Mesures et échéanciers

3.4.1 Le cadre de gestion de projet mis en place pour SXD exige déjà qu'une structure de répartition des travaux soit mise en place, comme indiqué dans la recommandation. Le degré de détails fournis dépend de la taille et de la portée du projet.

Échéancier : Terminé

4.0 Gestion de risque

4.1 Les livrables des projets analysés pendant la vérification ne comportaient aucune stratégie de gestion du risque. Certains projets ont identifié des risques au tout début de l'exécution, mais aucune mise à jour n'était fournie en cours d'exécution et il n'existait aucune stratégie d'atténuation.

La gestion du risque a pour but d'identifier les problèmes potentiels avant qu'ils ne se produisent, de façon que des activités puissent être planifiées et mises en place au besoin pendant la réalisation du projet pour atténuer les répercussions négatives à l'atteinte des objectifs du projet.

Selon l'Institut de génie logiciel (SEI)(20), pour se préparer à faire face aux risques, il faut établir et gérer une stratégie de détermination, d'analyse et d'atténuation des risques, intégrée à un plan de gestion du risque. Cette stratégie porte, quant à elle, sur les mesures et les méthodes de gestion nécessaires à la mise en application et au contrôle du programme de gestion du risque, notamment l'identification de l'origine du risque, la méthode utilisée pour classer les risques et les paramètres utilisés pour contrôler les risques dans le but d'y faire face.

La détermination de l'origine du risque forme la base de l'examen de la mouvance des situations en fonction du temps. Elle est effectuée dans le but de découvrir les circonstances pouvant nuire à l'atteinte des objectifs du projet. Les risques peuvent ainsi provenir tant de l'interne que de l'externe. En outre, d'autres sources de risques peuvent être décelées à mesure que le projet avance. L'établissement de catégories pour classer les risques fournit un mécanisme pour la collecte et la structuration des données liées aux risques et fait en sorte que des mesures d'examen et de gestion appropriées soient en place pour tenir compte des risques qui pourraient affecter gravement l'atteinte des objectifs du projet.

La gestion du risque pour les projets TI améliore la capacité du MAECI à gérer et à assurer la réalisation des livrables des projets TI. À l'échelle du projet, l'objectif de la gestion du risque consiste à évaluer de façon proactive ce qui pourrait « aller mal » dans un projet, à déterminer les risques dont il faut s'occuper et à mettre en oeuvre des stratégies pour faire face à ces risques.

Le cadre amélioré de gestion du Conseil du Trésor a adopté le processus de gestion du risque de l'Institut de génie logiciel (SEI)(21). Ainsi, chaque risque passe par des fonctions séquentielles. Les risques font l'objet d'un suivi simultané à la détermination et à l'analyse des nouveaux risques. En outre, le plan d'atténuation d'un risque en particulier peut entraîner d'autres risques pendant le cycle de vie du projet.

Processus de gestion du risque :

Processus de gestion du risque

Le tableau qui suit décrit les processus de gestion du risque.(22)

FonctionDescription
DéterminationRecherche et identification des risques avant qu'ils ne deviennent des problèmes.
AnalyseConversion des données liée aux risques en renseignements pour prise de décision. Évaluation des répercussions, de la probabilité, de l'échéancier, puis classification et établissement des priorités.
PlanConversion des données liées aux risques en décisions et mesures d'atténuation (actuelles et à venir) et mise en oeuvre de ces mesures.
SuiviSuivi des indicateurs de risque et des mesures d'atténuation.
ContrôleCorrection des déviations quant aux plans d'atténuation des risques.
CommunicationDiffusion d'informations et de commentaires, à l'interne comme à l'externe, quant aux activités de gestion du risques du projet, aux risques actuels et aux risques émergents (pendant la durée du projet).

Tous les projets comprennent des risques standard, notamment : répercussions pour le Ministère; répercussions sur des projets connexes; répercussions sur le recrutement, sur la taille du budget, sur l'accessibilité du budget, sur le nombre d'activités du plan du projet, sur le nombre de livrables du projet, sur les travaux nécessaires, sur la complexité, sur la portée des modifications à apporter aux fonctions opérationnelles; sur les compétences et l'expérience de l'équipe du projet, sur l'emploi d'une nouvelle technologie et sur le nombre de groupes qui participent au projet.

Au MAECI, l'équipe de vérification a trouvé deux projets qui comprenaient un plan de gestion du risque. Ainsi, l'énoncé du projet ITAMS comportait dix risques ainsi qu'une stratégie d'atténuation(23) pour chaque risque. De même, le DP du projet GeRC(24) comprenait des « défis liés au projet ». À cet effet, la DP précisait que la solution devait tenir compte des contraintes définies, qui étaient :

  • Topologies distinctes des 135 missions à l'échelle du globe;
  • Contraintes de nature technologique, y compris normes des ordinateurs, différences réseau, sécurité, normes des serveurs et exigences des plate-formes;
  • Contraintes du projet de renouvellement Signet 2000;
  • Déploiement des serveurs.

La DP du GeRC abordait en outre les délais serrés, la conversion des anciennes données, les exigences relatives au bilinguisme ainsi que la formation, à titre de risques supplémentaires.

Recommandation pour le bureau de gestion des projets

4.1.1 Le bureau de gestion des projets, de concert avec l'AIC, doit établir et imposer une stratégie formelle de gestion du risque pour les projets TI. Cette stratégie doit au moins porter sur les éléments suivants :

  • Portée des efforts en matière de gestion du risque;
  • Méthodes et outils à utiliser pour l'identification et l'analyse du risque, l'atténuation, la surveillance du risque et les communications;
  • Origine des risques particuliers au projet;
  • Façon dont les risques seront structurés, catégorisés, comparés et consolidés;
  • Paramètres, y compris probabilité, conséquences et seuil pour la prise de mesures concrètes en ce qui concerne les risques identifiés;
  • Techniques d'atténuation des risques à utiliser, notamment : prototypage, simulation, conception de rechange, programmation évolutionnaire;
  • Définition de mesures du risque pour assurer la vérification de l'état des risques;
  • Intervalles de surveillance ou de réévaluation des risques.

Mesures et échéancier

4.1.1 Même si SXD ne possède pas de stratégie formelle de gestion du risque, les livrables normalisés de projet (définis dans le cadre de gestion de projet) comprennent un modèle d'identification et d'analyse des risques.

Échéancier : Terminé

SXEM emploie des conseillers en gestion de projet chargés d'aider les gestionnaires de projet à colliger l'information et en mesure de fournir des conseils quant aux processus d'exécution à suivre.

SXEM passera en revue le CGP pour s'assurer que les points suggérés sont intégrés au modèle.

Échéancier : Fin octobre

Il existe un processus à SXD pour la production de rapports de progrès et d'état des projets dans le cadre de rencontres mensuelles avec le Comité de gestion de la Direction générale SXD. Tous les projets « à risque » sont abordés dans le cadre de la réunion, et des mesures concrètes sont déterminées et discutées, notamment dans le cadre d'un suivi lors de la rencontre du mois suivant.

Échéancier : Terminé

5.0 Formation

5.1 Compétences clés en gestion de projet

Pour atteindre le premier plateau du cadre amélioré de gestion du SCT, le MAECI doit s'assurer que les gestionnaires de projet possèdent les connaissances et l'expérience appropriées et qu'ils ont à leur disposition les outils qui les aident à réaliser les projets.

Même si certains des gestionnaires de projet interrogés dans le cadre de la vérification possédaient un diplôme universitaire (MBA), une seule des douze personnes comprise dans notre échantillon de projets a indiqué qu'elle avait reçu une formation « officielle » en gestion de projet. Par conséquent, nous en venons à la conclusion qu'au sein du MAECI, les gestionnaires de projet ont besoin de formation dans le but d'acquérir les compétences clés exigées par le Conseil du Trésor.

La gestion de projet suppose la mise en pratique de connaissances et de compétences et l'utilisation d'outils et de techniques dans le cadre des activités du projet afin de respecter les exigences du projet. Pour ce faire, il faut recourir à différents processus : mise en route, planification, réalisation, contrôle et clôture du projet. Nombre des processus intervenant dans la gestion des projets sont d'ailleurs itératifs.

Les compétences clés sont les compétences de base dont a besoin une personne chargée de la gestion d'un projet de technologie de l'information (TI) au sein du Gouvernement fédéral canadien.

La gestion de projet repose sur trois grands domaines de connaissances, indiqués dans le tableau plus loin.

Gestion générale : pratiques de gestion appropriées
Le gestionnaire de projet doit posséder des compétences en gestion générale. À ce titre, les compétences nécessaires portent sur le leadership, la négociation, la communication et la formation d'équipe.

Gestion de projet : qualité des processus et des résultats du projet
Le gestionnaire de projet doit comprendre les compétences généralement acceptées en gestion de projet, notamment : gestion de la portée du projet, échéancier, coûts et qualités.

Gestion de projet TI : établissement ou acquisition de projets TI de qualité
Le gestionnaire de projet TI doit posséder des compétences de gestion TI, notamment : détermination des phases du cycle de vie, évaluation et conception de logiciels.

Recommandation pour l'AIC

5.1.1 Le DPI doit s'assurer, par le biais du groupe des propriétaires des principales applications et du Comité directeur de la GIT, que tous les gestionnaires de projet, dans le cadre de leur formation permanente, participent à des cours de gestion de projet pour acquérir les compétences clés décrites par le Conseil du Trésor(25) ou par le Project Management Institute dans la version 2000 du Guide du référentiel des connaissances en gestion de projet (PMBOK).

Mesures et échéancier

5.1.1 De la formation en gestion de projet a été fournie à titre volontaire l'année dernière à SXD. En raison des contraintes liées aux ressources, il n'a pas été possible d'exiger des gestionnaires de projet qu'ils participent à ces cours. Si cette formation se révélait un succès, le programme pourrait être étendu à d'autres directions générales.

Échéancier : En cours

6.0 Pratiques exemplaires

Cette section décrit les pratiques trouvées au MAECI et que SIV considère comme des pratiques exemplaires, en plus d'aborder certaines des pratiques exemplaires de l'industrie privée.

6.1 Le cadre amélioré de la gestion (CAG) du Conseil du Trésor est formé de pratiques exemplaires, de principes, de méthodes, d'outils et de normes élaborés dans le cadre d'un projet interministériel et destinés à proposer des solutions aux problèmes de gestion de projet touchant le gouvernement fédéral. Les différents plateaux du CAG portent sur les étapes concrètes devant permettre d'améliorer de façon considérable la capacité du gouvernement de gérer et de réaliser des projets TI. Il tient compte des résultats préliminaires du cadre de travail évolué et des priorités établies par les ministères du gouvernement. (Pour plus de détails sur les exigences nécessaires à l'atteinte des différents plateaux, consultez http://www.cio-dpi.gc.ca/emf-cag/about/abu-ans04_f.asp.)

6.2 L'Institut de génie logiciel Carnegie Mellon a élaboré des principes et des pratiques en matière de stabilisation des processus logiciels qui pavent la voie permettant de passer de processus ad hoc et chaotiques à des processus logiciels stabilisés et disciplinés. Cette voie comporte cinq degrés de stabilisation. Pour plus de détails, consultez l'annexe B.

6.3 Des objectifs de contrôle pour les technologies de l'information et les technologies connexes (CobiT) ont été élaborés à titre de normes applicables, généralement acceptées en matière de pratiques exemplaires pour le contrôle des technologies de l'information (TI). CobiT est articulé autour des objectifs de contrôle de l'Information Systems Audit and Control Foundation (ISACF) auxquels s'ajoutent des normes existantes et émergentes dans les domaines techniques, professionnels, réglementaires et industriels internationaux. Pour plus de détails, consultez l'annexe C.

6.4 Les pratiques exemplaires ci-après sont définies par le Gartner Group dans son rapport sur le bureau de gestion des projets.

  • Les équipes de projet doivent être encouragées à se tenir à jour au moyen de courtes rencontres périodiques obligatoires et à identifier les facteurs critiques de succès;
  • Il faut procéder à un réévaluation des projets TI au début de chacune des phases importantes;
  • Le bureau de gestion des projets peut simplement servir de source d'information en matière de méthodes et de normes sur les projets. Ce bureau suppose que l'organisation utilise un ensemble cohérent d'outils pour la conception, la gestion et la production des rapports du projet. Ce modèle se retrouve souvent dans les organisations qui encouragent une responsabilisation répartie, centrée sur les processus de gestion;
  • Le bureau de gestion des projets peut partager sa base de données. Ce modèle suppose le désir de partager certaines pratiques de gestion de projet entre les différentes fonctions et se sert du bureau de gestion des projets pour coordonner les communications. Les pratiques exemplaires sont documentées et partagées, et le rendement fait l'objet d'une évaluation active. Les résultats permettent d'améliorer le rendement de l'organisation et d'assurer la formation des gestionnaires de projet peu efficaces ou nouveaux;
  • Les organisations qui se servent de critères rigoureux pour atteindre les objectifs des différentes étapes, depuis l'établissement des besoins jusqu'à la réalisation, économisent plus de 25% des frais attribuables à l'annulation des projets;(26)
  • On a recourt à la triangulation, en vertu de laquelle les coûts estimatifs établis au moyen de techniques diverses sont comparés jusqu'à ce que l'écart maximum soit de 10 % entre deux ensembles de résultats donnés(27).

6.5 SXEM - Concept du bureau de gestion des projets

Dans le cadre des travaux de cette vérification, l'équipe en est venue à la conclusion que SXEM avai déjà pris des mesures pour mettre en place certaines pratiques exemplaires au sein de SXD. Ces pratiques comprennent :

  • Production d'un rapport de gestion de projet pour le Ministère;
  • Mise en place de certaines fonctions du bureau de gestion des projets(28);
  • Établissement d'une base de données au MAECI pour ce qui est des éléments réutilisables pour les projets (par exemple : modèle de plan de projet, modèle d'établissement des coûts et composantes diverses);
  • Réalisation d'une conclusion de projet (par exemple : collecte de différentes données de mesure notamment : coût du projet, taille, qualité et satisfaction des utilisateurs).

6.6 SIGBM

Un ensemble stricte de normes est mis en vigueur pour chaque version du logiciel SIGBM. Le CD, qui comprend les données relatives à la version, propose les résultats des essais, les approbations d'acceptation par les utilisateurs et les analyses de rentabilisation.

6.7 COSMOS

Des tâches précises ont été affectées aux entrepreneurs au moyen de formulaires d'autorisation; ces fournisseurs devaient fournir une estimation des travaux et des délais, puis étaient responsables d'exécuter les activités conformément aux délais et aux devis fournis. Comme les entrepreneurs fournissaient une évaluation fixe des coûts, il n'y avait aucun coût excédentaire. L'utilisation de formulaires d'autorisation avec les contrats assure le respect des exigences conformément au budget établi, puisque l'entrepreneur fait une soumission à coût fixe.

6.8 ITAMS

Le projet ITAMS constitue un excellent exemple de l'intégration des activités d'approvisionnement au plan du projet. Le budget d'ITAMS définit les montants nécessaires à la gestion du projet et aux services des consultants externes. Le diagramme de l'analyse de rentabilisation du projet de novembre 2001(29) comprend aussi d'autres références à l'achat des permis d'utilisation des logiciels. La charte du projet ITAMS (24 juin 2002) détermine la personne responsable d'assurer le soutien à l'approvisionnement et les services-conseils.

6.9 Le bureau de gestion des projets peut élaborer une base des données de risques au moyen des données des projets réalisés. Cette base de données doit regrouper tous les risques déterminés et les stratégies d'atténuation de tous les projets TI réalisés au MAECI. Les gestionnaires de projet doivent être en mesure de consulter la base de données pour y rechercher les risques qui pourraient avoir des répercussions sur leurs projets TI.

7.0 Conclusion

L'équipe de vérification en vient à la conclusion qu'il existe des processus de gestion de projet de base au MAECI, et que les activités de gestion de projet du Ministère ont connu un certain succès. Toutefois, comme les normes de gestion de projet ne sont pas parfaitement documentées, ni intégrées à l'échelle du MAECI, ces succès sont marginaux et ne peuvent pas être facilement répétés.

Bien que l'ICSE et le SCT proposent un certain nombre de cours de gestion de projet, rien ne permet de croire que tous les gestionnaire de projet du MAECI ont suivi les cours appropriés ou possèdent les compétences clés suggérées par le Conseil du Trésor. Le Ministère doit prendre les mesures nécessaires pour s'assurer que tous les gestionnaires de projet possèdent les connaissances, l'expérience et les outils nécessaires à leur travail, avant de leur confier des projets de plusieurs millions de dollars.

Annexe A - Liste de vérification proposée des livrables de gestion de projet

Projets de petite envergure

Projets de moyenne envergure

Projets de grande envergure

Annexe B - Modéle de stabilisation des capacités

Le modèle de stabilisation des capacités (CMM) décrit les principes et les pratiques de stabilisation des processus logiciels et trace la voie permettant de passer de processus ad hoc et chaotiques à des processus logiciels stabilisés et disciplinés.

Modèle de stabilisation des capacités

Degré de stabilisation 1 : Initial

Les processus sont habituellement chaotiques et ad hoc. Le succès dépend donc de la compétence et des efforts des membres de l'organisation et non pas de l'utilisation de processus éprouvés. Ces organisations dépassent fréquemment les budgets et l'échéancier de projet, ont tendance à utiliser des processus pour ensuite les abandonner en temps de crise et ne sont pas en mesure de répéter leurs succès.

Degré de stabilisation 2 : Gestion

Les projets sont bien gérés et les processus sont planifiés, exécutés, mesurés et contrôlés. Les pratiques existantes demeurent en place, même au moment des crises, tandis que les processus, les produits et les services sont bien gérés. La direction peut facilement connaître l'état du projet. Les principaux intervenants prennent des engagements, qui font l'objet de révision au besoin.

Degré de stabilisation 3 : Définition

Les processus sont bien cernés et compris et font l'objet de descriptions dans des normes, des procédures, des outils ou des méthodes. Des processus standard servent à assurer l'uniformité au sein de l'organisation et sont adaptés aux projets à même un ensemble de processus standard de l'organisation. L'équipe de vérification en est venue à la conclusion que le MAECI n'avait pas encore atteint ce degré.

Degré de stabilisation 4 : Gestion quantitative

L'organisation possède des processus qui, grâce à des techniques quantitatives, contribuent de façon considérable au rendement du processus global. Le rendement et la qualité des processus sont bien compris du point de vue statistique et sont gérés pendant tout le cycle de vie des processus; ils sont en outre intégrés à la base de données de mesures de l'organisation qui sert par la suite à la prise de décisions éclairées. Les causes des variations sont déterminées et, le cas échéant, corrigées pour éviter qu'elles ne se répètent.

Degré de stabilisation 5 : Optimisation

Les objectifs quantitatifs d'amélioration des processus sont établis, révisés de façon permanente et servent de critère pour l'amélioration des processus de gestion. Cette amélioration fait partie inhérente du rôle de chaque personne, ce qui assure la mise en place d'un cycle permanent d'amélioration. Cet élément décrit les principes et les pratiques liés à la stabilisation du processus logiciel sous la forme d'une voie permettant de passer de processus ad hoc et chaotiques à des processus logiciels stabilisés et disciplinés.

Annexe C - Objectifs de contrôle des technologies de l'information et des technologies connexes (COBIT)

Des objectifs de contrôle pour les technologies de l'information et les technologies connexes (COBIT) ont été élaborés sous forme de normes généralement acceptées et applicables pour que les TI possèdent un cadre efficace de contrôle de la gestion et qu'il soit possible de répondre aux attentes des clients et de la direction. COBIT est articulé autour de normes existantes techniques, professionnelles, réglementaires et industrielles internationales et est dorénavant reconnu par le SCT comme un cadre applicable à l'analyse et à la vérification des systèmes d'information au Gouvernement du Canada.

COBIT

COBIT est destiné à trois groupes d'utilisateurs distincts :

  • Direction : Aider à équilibrer les risques et à contrôler les investissements dans un environnement de technologie de l'information souvent imprévisible. La direction a besoin de pratiques de contrôle et de gouvernance TI acceptées pour évaluer l'environnement TI en place et planifié. COBIT est un outil qui permet aux gestionnaires de verbaliser leurs exigences concurrentielles et de combler le vide entre les besoins de contrôle, les préoccupations techniques et les risques commerciaux.
  • Utilisateurs (c'est-à-dire responsables des processus de gestion)  : Assurer la sécurité et le contrôle des services de technologie de l'information fournis à l'interne ou par de tierces parties.
  • Vérificateurs des systèmes d'information : Appuyer leur opinion face à la direction quant aux contrôles internes.

Le méthode COBIT indique qu'il existe un grande nombre de processus distincts comportant de nombreux contrôles, mais qu'il existe aussi une façon systématique d'évaluer ces contrôles.

COBIT constitue un cadre de contrôle TI axé sur des critères d'information commerciale, documenté au moyen d'objectifs de contrôle classés par domaine, processus et activité TI. Chaque secteur comporte en outre un ensemble d'objectifs de contrôle, une définition et un motif de contrôle.

Le principal thème à l'origine du COBIT est l'orientation commerciale; COBIT est conçu non seulement à l'intention des utilisateurs et des vérificateurs, mais aussi, et c'est ce qui est le plus important, à l'intention des responsables des processus de gestion à qui il propose une liste de vérification exhaustive. Les pratiques commerciales supposent l'imputation complète des responsables des processus de gestion qui assument la responsabilité pleine et entière de tous les aspects de ces processus. Cela suppose la mise à leur disposition de mesures de contrôle appropriées. COBIT met à la disposition du responsable des processus de gestion un outil qui facilite la prise en charge de cette responsabilté.

Le cadre de travail COBIT est articulé autour d'un concept fort simple : pour être en mesure de fournir à l'organisation l'information dont elle a besoin pour atteindre ses objectifs, les ressources TI doivent être gérées au moyen d'un ensemble de processus naturellement regroupés. Les domaines sont identifiés au moyen de termes qu'utilise la direction dans ses activités quotidiennes de gestion de l'organisation :

  • Planification et organisation - Ce domaine regroupe des stratégies et tactiques, et porte sur la détermination de la façon dont les technologies de l'information peuvent contribuer à l'atteinte des objectifs du Ministère.
  • Acquisition et mise en oeuvre - La réalisation de la stratégie TI suppose l'identification, l'élaboration ou l'achat de solutions TI ainsi que leur mise en oeuvre et intégration aux processus de gestion.
  • Livraison et soutien - Ce domaine porte sur la prestation de services réels, qui varient des questions classiques de sécurité et de continuité des affaires à la formation. Pour assurer la prestation des services, les processus de soutien nécessaires doivent être mis en place.
  • Surveillance des processus - Tous les processus TI doivent faire l'objet d'une évaluation régulière en ce qui a trait à leur qualité et à leur conformité aux exigences de contrôle.

Pour plus de détails sur le COBIT consultez l'adresse http://www.isaca.org.

Annexe D - Exemples de projets

EQAMS - Système de gestion électronique des questions et réponses

Propose une seule base de données des Q et R. Permet aux auteurs, aux superviseurs et aux contributeurs de créer, réviser, modifier et imprimer des Q et R. Permet de procéder à la traduction des Q et R à même le système, pour les mettre immédiatement à la disposition des utilisateurs. Permet à certains employés des cabinets des ministres et des secrétaires d'État de passer les Q et R en revue, de créer des réponses ministérielles et de catégoriser chaque Q et R.

ITAMS - Système de gestion des biens liés à la technologie de l'information

Le projet ITAMS, de même que les procédures et les politiques ministérielles qui l'appuient, ont pour but de mettre à la disposition de SXD des outils pour améliorer la gestion de ses éléments d'actifs ou pour offrir du soutien à l'Administration centrale ou aux personnes sur place dans les missions.

Micro-missions

Les services TI et de communication mis à la disposition des micro-missions ne suffisent pas à l'atteinte des objectifs du MAECI. Ce projet a pour but de mettre les micro-missions à niveau avec les services de base de communication et TI approuvés. Le projet assure également la mise en place des ressources et des mécanismes de soutien nécessaires à l'entretien de ces services dans les micro-missions ciblées.

IR - Renouvellement de l'infrastructure

Mise à jour des systèmes d'exploitation et remplacement des serveurs désuets. Le projet permettra au MAECI d'assurer l'interopérabilité avec les organismes externes.

COSMOS - Système de gestion des opérations consulaires

Permet au personnel des opérations consulaires de l'Administration centrale et des missions d'avoir accès à un ensemble d'outils conçus pour faciliter la gestion des affaires consulaires.

Connex

Méthode permettant au GDG-E de conserver les données sur les contacts et les activités. Dans le but d'assurer des contacts permanents avec les Canadiens, il est essentiel et urgent d'établir une base de données centralisée sur les contacts et les participants pour l'analyse, la production, la vérification, les communications et le marketing. La base de données des contacts regroupe toutes les données sur les contacts et permet aux utilisateurs de récupérer et de mettre à jour cette information. Elle sert également à préparer, diffuser et transmettre de l'information aux intervenants.

Module RE/PM - Immobilier/maintenance

Essai pilote du module immobilier/maintenance du SAP. Ce projet comprend également l'évaluation du progiciel Prime Real Estate.

SGCM - Système de gestion de la correspondance ministérielle

Met à la disposition du Ministre un système sécuritaire et stable permettant de stocker et de récupérer la correspondance ministérielle et la documentation connexe dans le but de répondre aux exigences législatives liées à la gestion de l'information du gouvernement et à l'accès à l'information.

GeRC - Gestion électronique des relations avec la clientèle

Remplace les anciens systèmes de gestion des contacts des agents de commerce (par exemple WIN Online, Mission WIN, Maximizer et ContactsPlus) par une application commerciale. Permet aussi aux agents de commerce à l'étranger d'accéder, de partout et en tout temps, aux demandes de service et d'information au moyen d'ordinateurs portatifs, de téléphones cellulaires ou d'assistants numériques personnels (ANP).

IA - Intelligence d'affaires

Fournit de l'information commerciale intersectorielle à jour pour appuyer la prise de décision et traiter de façon efficace et responsable les questions d'imputabilité et d'intendance des ressources. Répond aux besoins de l'Administration centrale et des missions en intégrant et en proposant de l'information tirée des principaux systèmes du Ministère.

FAC - Faire des affaires avec le Canada

Met à la disposition des entreprises et des bureaux du gouvernement canadien à l'étranger un guichet unique d'information sur la façon de faire des affaires avec le Canada, en intégrant les différents programmes et services du gouvernement canadien dans une application en ligne destinée aux entreprises à l'étranger.

DCV - Délégué commercial virtuel

Permet au Ministère de proposer des services en ligne personnalisés et adaptés aux exportateurs, aux délégués commerciaux et aux responsables d'entreprises à l'étranger ou au Canada.

Annexe E - Planification de contrat

Notes générales :

  1. Organiser une rencontre avec l'agent des marchés au début de la phase de planification du projet.
  2. Toutes exceptions à ces étapes de planification peuvent être abordées avec SMFG.
  3. Consulter SMFG pour déterminer le délai estimatif entre la définition des besoins et l'attribution du contrat.

1. Définition des besoins

  1. Préparation de l'énoncé des travaux.
  2. Évaluation des coûts.
    1. La valeur totale estimative peut être supérieure à 2 000 000 $ lors de l'utilisation de MERX (appel d'offres concurrentiel).
    2. La valeur estimative totale ne peut être supérieure à 400 000 $ lors d'un appel d'offres classique (concurrentiel).
    3. La valeur estimative totale ne peut être supérieure à 25 000 $ pour les contrats à fournisseur exclusif et, dans certains cas, 100 000 $.

    * Si la valeur estimative totale est supérieure aux montants inscrits dans (b). i., ii., iii. ci-dessus, il faut obtenir l'approbation du Conseil du Trésor ou transmettre une demande à TPSGC pour l'adjudication du contrat.
  3. L'élaboration/préparation du document d'appel d'offres et de la grille d'évaluation (pour les contrats accordés à l'appel d'offres concurrentiels).
    • Demande de propositions
    • Demande d'offres permanente

2. Pertinence des accords commerciaux et des seuils contractuels du Conseil du Trésor

Déterminer si le besoin est assujetti à un accord commercial. Lorsque au moins un accord commercial s'applique, la demande doit être affichée sur MERX pendant un minimum de 40 jours.

  • Accord sur le commerce intérieur (ACI)
  • Accord de libre-échange nord-américain (ALENA)
  • Organisation mondiale du commerce (OMC)

3. Évaluation des soumissions et préparation du contrat/offre permanente et/ou contrat d'approvisionnement

4. Approbation par le Comité d'examen des marchés

5. Adjudication et administration du contrat

TPSGC

1. Définition des besoins

  • Préparation de l'énoncé des travaux.
  • Préparation/élaboration de l'appel d'offres et de la grille d'évaluation (dans le cas des contrats adjugés par appel d'offres concurrentiel).

2. Pertinence des accords commerciaux et des seuils contractuels du Conseil du Trésor

Déterminer si le besoin est assujetti à un accord commercial. Lorsque au moins un accord commercial s'applique, la demande doit être affichée sur MERX pendant un minimum de 40 jours.

  • Accord de libre-échange nord-américain (ALENA)
  • Organisation mondiale du commerce (OMC)

3. Évaluation des soumissions et préparation du contrat/offre permanente et/ou contrat d'approvisionnement

4. Processus d'approbation des contrats TPSGC

5. Adjudication et administration du contrat


1 Analyse de la gestion des applications, Consultants CGI en gestion et systèmes d'information, mai 2003 Retourner

2 Page 4 Retourner

3 Intégration du modèle de stabilisation des capacités, version 1.1 par l'Institut de génie logiciel Carnegie Mellone, section GP 2.4, page 40 Retourner

4 Intégration du modèle de stabilisation des capacités, version 1.1 par l'Institut de génie logiciel Carnegie Mellon, section SG 1.1.4, page 124 Retourner

5 Page 16, paragraphe 4.4 Retourner

6 Rapport du vérificateur général, décembre 2000, page 23-9 Retourner

7 Page 9, paragraphe 3.2.3 Retourner

8 Principe CAG 4.2.2.3, page 9 et principe CAG 4.2.4.5, page 16 Retourner

9 La solution temporaire indique 2 jours pour l'achat de PC plats et 2 autres jours pour l'achat de Lotus Notes Cals. En outre, la tâche 42 du plan de projet indique 93 jours pour l'acquisition des ressources, des tablettes PC et des postes de travail Signet. Le plan de projet comprend les dates prévues de début/fin de ces activités et précise qu'elles ont été réalisées à temps. Retourner

10 http://www.gao.gov/special.pubs/ai98089.pdf - Mesure du rendement et démonstration des résultats des investissements en technologie de l'information, GAO, mars 1998 Retourner

11 http://www.cio-dpi.gc.ca/emf-cag/model/ed-td/ed-td_f.asp Retourner

12 Analyse de la gestion des applications, page 11 Retourner

13 Analyse de la gestion des applications, page 12 Retourner

14 Politique sur le processus d'approbation des projets de gestion de l'information et des technologies de l'information, http://intranet.dfait-maeci.gc.ca/department/cio/proManagement/tracking/policyProcess-fr.asp#1 Retourner

15 http://intranet.dfait-maeci.gc.ca/department/cio/responsible-fr.asp Retourner

16 Cadre amélioré de la gestion du SCT page 10 Retourner

17 Appelé Acceptation du projet Retourner

18 http://intranet.dfait-maeci.gc.ca/department/cio/proManagement/tracking/policyProcess-fr.asp Retourner

19 Ces normes sont en cours de révision et étaient à jour au moment de la vérification. Retourner

20 Intégration du modèle de stabilisation des capacités (CMMISM), version 1.1 page 381, Degré de stabilisation 3 : Gestion du risque Retourner

21 www.sei.cmu.edu/programs/sepm/risk/index.html Retourner

22 Cadre amélioré, pour la gestion des projets de TI - Partie 2 - Solutions pour l'application des principes. Chapitre 4, Solutions améliorées. www.cio-dpi.gc.ca/emf-cag/ppw-slp/ppw-slp04_f.asp Retourner

23 Page 8 Retourner

24 Chapitre 6 de la page 39 de la DP Retourner

25 Cadre amélioré pour la gestion des projets de technologie de l'information, COMPÉTENCES DE BASE EN GESTION DE PROJET, mars 1998, Bureau de gestion des projets du Bureau du dirigeant principal de l'information - Secrétariat du Conseil du Trésor du Canada Retourner

26 Le bureau de gestion des projets : équipes, page 17 Retourner

27 Le bureau de gestion des projets : équipes, page 17 Retourner

28 Le bureau de gestion des projets : équipes, page 13 Retourner

29 Page 53 Retourner

Bureau de l'inspecteur général

Pied de page

Date de modification :
2008-11-10