Audit de la version pilote du projet de Modernisation des applications du spectre - Mise en œuvre d’un logiciel commercial (MAS-MLC)


Liste des sigles et acronymes utilisés dans le rapport

AQ
Assurance de la qualité
BPI
Bureau principal de l'information
DG
Directeur général
DGVE
Direction générale de la vérification et de l'évaluation
ISDE
Innovation, Sciences et Développement économique
LDSM
Logiciel disponible sur le marché
MAS-MLC
modernisation des applications du spectre — mise en oeuvre d'un logiciel commercial
SCT
Secrétariat du Conseil du Trésor du Canada
SGS
Système de gestion du spectre
SMA
Sous-ministre adjoint
SPC
Services partagés Canada
SST
Secteur du spectre et des télécommunications
TI
Technologie de l'information

1.0 Sommaire

1.1 Introduction

Aperçu de la gestion du spectre :

  • Environ 697 employés avec un budget de 62,8 millions de dollars
  • Revenus liés aux licences radio s'élevant à 295 millions de dollars en 2016-2017
  • Revenus liés aux enchères atteignant 837 millions de dollars en 2016-2017
  • Plus de 62 000 Canadiens et services commerciaux possèdent une licence pour l'utilisation du spectre des radiofréquences

Le projet de Modernisation des applications du spectre – mise en œuvre d'un logiciel commercial (MAS-MLC) a été mis en place en vue de déterminer les répercussions des applications de technologie de l'information (TI) vieillissantes sur le programme de gestion du spectre (le programme). Le programme administre le spectre des radiofréquences, une ressource unique qui touche presque tous les aspects de la société canadienne en soutenant les télécommunications mobiles et sans fil. L'objectif du programme est de soutenir le Secteur du spectre et des télécommunications (SST) dans la réalisation de son mandat en maximisant les avantages économiques et sociaux que l'utilisation du spectre des radiofréquences procure aux Canadiens.

Les agents de gestion du spectre utilisent le Système de gestion du spectre (SGS) interne personnalisé pour percevoir les revenus des licences radio et les revenus annualisés provenant des enchères du spectre. Le SGS constitue l'ensemble essentiel d'outils logiciels dont se sert le personnel du programme pour administrer les autorisations, émettre les factures des droits de licence associés à ces autorisations et surveiller la couverture du signal, le brouillage possible et la conformité à la politique.

Le SGS actuel se compose d'un ensemble de vieilles applications et de technologies connexes qui ne peuvent plus être adéquatement entretenues. Bon nombre des plateformes de développement sont maintenant désuètes et approchent de la fin de leur vie utile. Le SGS est donc devenu difficile à entretenir parce que le logiciel n'est plus pris en charge et que sa capacité à répondre aux besoins du nouveau programme est limitée.

Pour traiter la question de la fin de la durée de vie utile, les responsables du programme ont décidé d'acheter un logiciel disponible sur le marché (LDSM) pour remplacer le SGS désuet, plutôt que de développer un autre système interne personnalisé.

Le travail de conception et de mise en œuvre du projet de MAS-MLC a débuté en septembre 2012 et devait se terminer en mars  2016. Le coût total du projet, estimé à 55 millions de dollars, devait être financé à partir des niveaux de référence ministériels existants.

1.2 Contexte de l'audit

L'objectif du présent audit était d'évaluer la pertinence des contrôles liés aux activités et aux processus appuyant la mise en œuvre du projet, conformément à l'expérience de la version pilote (date de déploiement : 20 mai 2014) et de la version 1 – lancement 1 (date de déploiement : 16 mars 2015).

La portée de l'audit comprenait les processus et les activités ayant trait aux domaines suivants :

  • Exigences opérationnelles et changements apportés aux exigences;
  • Gestion du changement et processus, activités et résultats relatifs à la préparation organisationnelle;
  • Gestion du budget, du calendrier et de la portée du projet;
  • Processus d'assurance de la qualité et prise en charge du logiciel;
  • Migration des données provenant des anciens systèmes;
  • Mise en œuvre des leçons tirées de la version pilote et de la version 1 – lancement 1 au profit des versions ultérieures.

1.3 Aperçu des résultats de l'audit

Points forts

  • La direction du projet de MAS-MLC a élaboré des plans pour répondre aux exigences en matière de gestion du changement de l'organisation afin d'appuyer le projet de MAS-MLC.
  • Un cadre de gestion du projet a été élaboré et mis en œuvre et une surveillance a été mise en place.
  • Une stratégie complète d'essai a été établie pour appuyer le développement de logiciels.
  • Des plans complets de migration des données ont été élaborés et mis en œuvre et sont régulièrement surveillés.
  • L'équipe du projet de MAS-MLC a intégré les leçons tirées de la version pilote au profit du travail lié aux versions ultérieures.

Points à améliorer

Les possibilités d'amélioration ci-dessous ont été définies dans le cadre de l'audit :

  • Les plans de gestion du changement n'ont pas été révisés pour tenir compte des difficultés observées lors du déploiement du projet.
  • Il n'y a pas de système de mesure du rendement élaboré pour suivre les améliorations prévues des nouveaux processus opérationnels.
  • Le paiement a été effectué au complet malgré les problèmes de rendement notés dans le développement du logiciel. L'engagement à corriger les problèmes n'a pas été officialisé.
  • Les essais par les utilisateurs finaux ont été réduits par rapport au plan et ne reflétaient pas l'utilisation réelle de l'application logicielle complète.

1.4 Opinion et conclusion de l'audit

Les résultats de l'audit ont révélé que les activités et les processus liés au contrôle du projet appuient sa mise en œuvre à quelques exceptions près. La gouvernance du projet est en place et la gestion de la migration des données est efficace. Il existe des possibilités de renforcer l'assurance de la qualité et les activités liées aux essais, ainsi que la planification à plus long terme de la prise en charge et de l'entretien du logiciel.

1.5 Réponse de la direction

La direction a accepté les constatations énoncées dans le présent rapport et prendra des mesures pour donner suite à toutes les recommandations d'ici le 31 décembre 2018.

1.6 Énoncé de conformité

L'audit a été effectué conformément aux normes relatives à la vérification interne du gouvernement du Canada, comme en témoignent les résultats du programme d'assurance et d'amélioration de la qualité de la Direction générale de la vérification et de l'évaluation.

space to insert signature

Michelle Gravelle
Dirigeante principale de la vérification
Innovation, Sciences et Développement économique Canada

2.0 À propos de l'audit

2.1 Contexte

Le ministre d'Innovation, Sciences et Développement économique Canada (ISDE) est responsable de la gestion du spectre au Canada : élaborer les politiques nationales et les objectifs visant l'utilisation des ressources du spectre, et assurer une gestion efficace des ressources du spectre des radiofréquencesNotes de bas de page 1. Au sein d'ISDE, la gestion du spectre des radiofréquences est assurée par le Secteur du spectre et des télécommunications (SST) par l'intermédiaire du Programme de gestion du spectre (le programme). L'objectif du programme est d'optimiser les avantages économiques et sociaux résultant de l'utilisation des ressources du spectre des radiofréquences dans l'intérêt de la population canadienne.

Le programme utilise un système interne personnalisé de gestion du spectre (SGS) pour administrer les autorisations, émettre les factures des droits de licence associés à ces autorisations et surveiller la couverture du signal, le brouillage possible et la conformité à la politique. Le système sert aussi à la coordination et à la gestion des assignations des radiofréquences entre le Canada et les États-Unis, et il sert d'interface pour les demandes d'information provenant des clients et du grand public. Le SGS actuel se compose d'un ensemble d'applications de TI et de technologies connexes vieilles d'une dizaine d'années qui ne peuvent plus être adéquatement entretenues ou améliorées. Bon nombre des plateformes de développement sont maintenant désuètes et approchent de la fin de leur vie utile. Le SGS a donc atteint la fin de sa durée de vie utile, les composantes ayant été réparées, et il est devenu complexe, instable et difficile à entretenir.

Le projet de Modernisation des applications du spectre – mise en œuvre d'un logiciel commercial (MAS-MLC) a été mis en place en vue de remplacer la plupart des applications vieillissantes du SGS. Le projet de MAS-MLC représente l'un des plus importants projets de développement de système de TI qu'ISDE a entrepris au cours des dix dernières années, le coût du projet étant estimé à 55 millions de dollars.

Un contrat a été établi en collaboration avec Services publics et Approvisionnement Canada, dans le but de fournir un logiciel disponible sur le marché (LDSM) et de le personnaliser s'il y a lieu. La mise en œuvre du projet de MAS-MLC représentait aussi une occasion de rationaliser et de normaliser les processus opérationnels.

Le projet de MAS-MLC est administré par une équipe de gestion de projet attitrée, qui collabore avec une équipe chargée de l'assurance de la qualité des logiciels, ainsi qu'avec les responsables opérationnels et fonctionnels ainsi qu'avec des experts en la matière dans différents secteurs de service. Le projet est mis en place en trois étapes : version pilote; version 1 (étape divisée en deux : lancement 1 et lancement 2); version 2.

2.2 Objectif et portée de l'audit

Objectif

L'objectif du présent audit était d'évaluer la pertinence des contrôles liés aux activités et aux processus appuyant la mise en œuvre du projet, conformément à l'expérience de la version pilote (date de déploiement : 20 mai 2014) et de la version 1 – lancement 1 (date de déploiement : 16 mars 2015). Les versions ultérieures du projet de MAS-MLC (version 1 – lancement 2 et version 2) dépassent la portée du présent audit.

Portée

La portée de l'audit comprenait les processus et les activités ayant trait aux domaines suivants :

  • Exigences opérationnelles et changements apportés aux exigences;
  • Gestion du changement et processus, activités et résultats relatifs à la préparation organisationnelle;
  • Gestion du budget, du calendrier et de la portée du projet;
  • Processus d'assurance de la qualité et prise en charge du logiciel;
  • Migration des données provenant des anciens systèmes;
  • Mise en œuvre des leçons tirées de la version pilote et de la version 1 – lancement 1 au profit des versions ultérieures.

2.3 Méthodologie

L'audit a été mené conformément aux normes relatives à la vérification interne du gouvernement du Canada. Des procédures d'audit suffisantes et pertinentes ont été appliquées, et des données ont été recueillies pour étayer la conclusion et l'opinion contenues dans le présent rapport. Cette opinion se fonde sur la comparaison des conditions qui prévalaient au moment de l'audit, en fonction des critères d'audit discutés avec la direction.

L'audit a été mené en trois étapes : la planification, le déroulement et la production du rapport. Une évaluation des risques a été réalisée durant l'étape de planification du présent audit de manière à confirmer l'objectif de l'audit et à déterminer les domaines nécessitant un examen plus approfondi durant l'étape du déroulement.

En fonction des risques cernés, la Direction générale de la vérification et de l'évaluation (DGVE) a élaboré des critères d'audit en lien avec l'objectif général de l'audit (consulter l'annexe A).

La méthodologie employée pour réaliser l'objectif de l'audit englobe les aspects suivants :

  • Examen et révision des documents;
  • Exécution de 25 entrevues auprès du personnel de l'équipe du projet de MAS-MLC, du SST, du Bureau principal de l'information (BPI), du fournisseur et des clients externes.

Toutes les données probantes de l'audit recueillies lors des processus indiqués ci-dessus ont été résumées et analysées, et étayent les constatations de l'audit présentées dans le présent rapport.

3.0 Constations et recommandations

3.1 Introduction

La présente section décrit les constatations détaillées de l'audit du projet de MAS-MLC. Les constatations sont fondées sur les preuves et l'analyse tirées de l'évaluation des risques initiale et de l'audit détaillé. Outre les constatations présentées ci-dessous, la DGVE a présenté à la direction, verbalement ou dans une lettre de recommandation, des observations sur les conditions non systémiques, de faible importance ou à faible risque.

3.2 Gestion du changement et préparation organisationnelle

La direction du projet de MAS-MLC a élaboré des plans pour répondre aux exigences en matière de gestion du changement de l'organisation afin d'appuyer le projet de MAS-MLC. Toutefois, ces plans n'ont pas fait l'objet d'une mise à jour continue au fur et à mesure de l'évolution des exigences opérationnelles.

Le projet de MAS-MLC apporte des changements aux processus opérationnels et aux technologies de l'information actuellement utilisés. Étant donné la portée de la transformation organisationnelle, des plans de gestion du changement doivent être en place pour déterminer une approche qui permettra la transition de l'organisation opérationnelle vers le nouvel environnement proposé et de s'assurer que l'organisation est prête à mener ses activités avec succès à l'aide des nouveaux outils et processus normalisés. De plus, il doit y avoir un plan pour la mise hors service des anciennes applications qui sont remplacées par la nouvelle solution.

Une stratégie et un plan de gestion du changement ont été élaborés durant l'étape de planification du projet. La stratégie a offert une description globale des besoins du programme en matière de gestion du changement à laquelle s'ajoutait un plan de gestion du changement qui présentait un plan d'action détaillé pour la version pilote du projet de MAS-MLC. Il décrivait aussi les stratégies de communication et de formation pour le programme appliquées au projet de MAS-MLC. Les activités et les processus de gestion du changement qui appuient la stratégie et le plan comprennent :

  • l'établissement d'un réseau du changement dans l'ensemble de l'organisation comprenant une personne responsable des communications et de la gestion du changement;
  • la détermination des exigences particulières en matière de changement des processus opérationnels;
  • les activités de sensibilisation et de communication;
  • l'évaluation de la préparation au changement;
  • la prestation de séances de formation.

Même si un plan complet a été élaboré, ce ne sont pas toutes les activités qui ont été réalisées conformément à l'engagement. Des problèmes relatifs à la formation et à la communication ont été notés par les clients externes, qui ont indiqué qu'ils n'avaient pas reçu l'information nécessaire afin de se préparer adéquatement en vue du nouveau système. Les documents et le matériel de formation n'ont pas été terminés à temps pour l'utilisation, si bien que la formation a été donnée sur un système logiciel provisoire en cours de développement qui ne correspondait pas au système final mis en production.

Le programme a reconnu ces difficultés et a apporté des améliorations aux versions ultérieures dans le but de résoudre les problèmes rencontrés avec la version pilote. Les changements comprennent l'élaboration de nouveaux outils de communication, ciblant les utilisateurs internes et les clients externes, dans le but d'établir un dialogue plus efficace, ainsi que de désigner le personnel responsable de gérer et de mettre à jour les documents.

De plus, les responsables du programme ont commencé à familiariser tout le personnel régional à la version pilote existante afin de faciliter la formation liée à la future version 2. Ils ont aussi poursuivi l'affectation d'un cadre supérieur ayant de l'expérience relative aux opérations du spectre pour collaborer étroitement avec l'équipe de projet et la direction des opérations régionales afin d'appuyer la préparation organisationnelle. Même si la direction a entrepris de concrétiser la transition en vue des versions ultérieures, ces mises à jour n'ont pas été documentées dans le plan de gestion du changement et aucun plan ne traite de l'ensemble du cycle de vie du projet au-delà de la version pilote.

Par conséquent, il y a des risques que les activités de gestion du changement ne préparent pas adéquatement les utilisateurs à exercer leurs activités à l'aide du nouveau système de MAS-MLC et des nouveaux processus normalisés. Enfin, les clients externes pourraient ne pas connaître suffisamment le nouvel outil de TI pour soumettre des demandes de licence selon le nouveau processus.

Le modèle de soutien d'ISDE n'est pas complètement défini au-delà de la date de fin du projet du 31 mars 2016. Sans un modèle de soutien bien défini, il y a un risque que les responsabilités des intervenants, ainsi que les exigences en matière de soutien, ne soient pas claires pendant la période d'entretien, tout comme pour l'état opérationnel et du soutien à long terme du projet de MAS-MLC et des anciennes applications.

Le plan de mise hors service pour atteindre le résultat souhaité de mise hors service de 80 % des anciennes applications est en cours. Cependant, il n'y a pas de calendrier et le plan n'a pas été finalisé ni approuvé. Il y a donc un risque que l'objectif pour la mise hors service ne soit pas atteint en temps voulu et que des coûts supplémentaires pour l'organisation soient engendrés pour le maintien de l'ancien système et du nouveau système.

Recommandation 1

Le DG de la Direction générale des opérations de gestion du spectre devrait s'assurer de ce qui suit :

  1. Le plan de gestion du changement est un document évolutif et mis à jour régulièrement, et comprend les versions ultérieures et la phase suivant la mise en œuvre. Le plan mis à jour devrait comprendre les activités à exécuter pour la communication, la documentation et la formation, et les activités de suivi postérieures à la mise en œuvre.
  2. En consultation avec SPC et la direction du BPI, le plan de transition, le plan de modèle de soutien et le plan de mise hors service sont finalisés et approuvés avant l'achèvement du projet.
Même si le programme vise à faire évoluer ses processus opérationnels pour appuyer le projet de MAS-MLC, il n'existe actuellement pas de système permettant de mesurer le rendement des améliorations des processus opérationnels et d'en rendre compte.

L'objectif du programme est de tirer parti des fonctionnalités de base du système commercial et, le cas échéant et si possible, de mettre à jour ou de repenser les processus opérationnels pour appuyer les fonctionnalités de base. En outre, le programme utilise le projet de MAS-MLC comme occasion de normaliser et de regrouper les processus opérationnels partout au pays. L'un des avantages à tirer de l'initiative, comme décrit dans l'analyse de rentabilisation du projet, est que le nouveau système fera le suivi des processus normalisés et regroupés et rendra des comptes à cet égard.

Tandis que des rapports sont générés régulièrement pour surveiller les activités de projet, des indicateurs clés doivent encore être élaborés pour effectuer le suivi des nouveaux processus normalisés et regroupés ou du rendement par rapport à des résultats prédéfinis et d'en rendre compte. Les responsables du programme ont reconnu cette nécessité et, au moment de l'audit, envisageaient d'établir des indicateurs clés et de nouvelles mesures de rendement.

L'absence de définition et de surveillance des mesures de rendement peut mener à des processus opérationnels inefficaces, ce qui nuiera à la productivité et à la satisfaction des utilisateurs internes et des clients externes. Il existe également le risque que la direction ne prenne pas de décisions éclairées sur la question à savoir s'il faut modifier les processus opérationnels et sur la façon de les modifier.

Recommandation 2

Le DG de la Direction générale des opérations de gestion du spectre devrait superviser l'élaboration et la mise en œuvre d'une approche de mesure du rendement, pour faire le suivi de la rapidité et de l'efficacité des principaux processus opérationnels à l'échelle du pays, améliorer la prise de décisions, et permettre la prise de mesures correctives en temps opportun. Cette approche devrait comprendre l'élaboration d'indicateurs de rendement clés harmonisés avec les buts opérationnels.

3.3 Gestion de projet

Un cadre de gestion du projet a été élaboré et mis en œuvre et une surveillance a été mise en place. Cependant, un paiement intégral a été effectué malgré les problèmes de rendement constatés lors du développement du logiciel. Les engagements pris pour résoudre les problèmes n'ont pas été officialisés.

Il est important de mettre en place des processus pour gérer activement tous les aspects du projet, y compris la gestion des budgets et du calendrier, de la portée et des exigences opérationnelles du projet pour s'assurer que le système de TI fourni répond aux besoins du programme et aux résultats attendus.

La charte du projet de MAS-MLC est un document important qui établit le cadre de gestion du projet en définissant la gouvernance du projet et la structure de l'équipe de projet. Elle fournit également un aperçu des divers processus de gestion du projet, y compris ceux relatifs à la gestion du budget, de la portée et du calendrier. La charte décrit également les activités liées à la gestion des exigences opérationnelles.

Le comité directeur du projet a approuvé la portée, le calendrier et le budget de la version pilote en septembre 2012. À ce moment-là, le directeur du projet a présenté au comité directeur la ventilation des dépenses maximales pour les services professionnels du fournisseur. La valeur totale des services professionnels correspondait aux estimations fournies dans les documents d'approbation définitive du projet ainsi que dans le contrat existant.

Des processus sont en place pour gérer et contrôler les budgets, le calendrier et la portée, ainsi que les exigences opérationnelles. De multiples outils, notamment les structures de répartition du travail et les chemins critiques, ont été élaborés pour effectuer un suivi des progrès réalisés par rapport au calendrier du projet. Un examen de ces documents a montré qu'ils avaient été mis à jour pour tenir compte des modifications du calendrier des déploiements de la version pilote et de la version 1 – lancement 1.

La portée du projet était gérée de manière à soutenir le résultat du projet de mise hors service des anciennes applications. De même, les exigences opérationnelles ont été définies, examinées et approuvées à l'aide de la participation des intervenants appropriés. Un processus officiel est en place pour traiter les demandes de changement qui touchent la portée, le budget ou le calendrier du projet.

Au niveau de la haute direction, les organismes de surveillances, notamment le comité directeur du projet et le comité exécutif de surveillance des projets du Secrétariat du Conseil du Trésor (SCT), reçoivent des rapports comparant le budget aux dépenses réelles et un résumé de l'état global et du niveau d'avancement du projet (p. ex. portée, calendrier et problèmes).

Gestion de la qualité

La liste des produits livrables essentiels au contrat définit les livrables attendus du fournisseur pour le projet. Même si le logiciel fournit un niveau de fonctionnalité permettant le traitement et la délivrance de licences et de certificats, l'audit a permis de déterminer que les éléments clés du logiciel lancé dans le cadre de la version pilote et de la version 1 – lancement 1 ne satisfaisaient pas toutes les exigences définies dans la liste des produits livrables essentiels au contrat. Dans certains cas, les versions nécessitaient des solutions de rechange ou des corrections en postproduction afin de répondre aux besoins opérationnels.

Après la version pilote, il a été décidé que, dans le cadre de la liste des produits livrables essentiels au contrat, les défauts non corrigés qui ne constituaient pas un obstacle à la délivrance de licences et de certificats devaient être classés par ordre de priorité et corrigés avant la fin du projet à l'aide de versions subséquentes. Au moment de l'audit, l'ordre de priorité n'avait pas encore été établi.

Le report de certains produits livrables énoncés dans la liste des produits livrables essentiels au contrat ne s'est pas traduit par une modification au contrat et aucune modification n'a été réalisée pour changer les échéanciers du projet. Sans une modification officielle du contrat, il y a un risque pour l'organisation que les lacunes ne soient pas corrigées comme prévu ou que les possibilités de résolution des problèmes soient limitées, le cas échéant. Les responsables du programme ont indiqué que ces versions ne seront pas considérées comme entièrement acceptées pour s'assurer que le fournisseur respectera ses engagements, mais le paiement intégral a été effectué au fournisseur pour les deux versions.

Recommandation 3

Le DG de la Direction générale des opérations de gestion du spectre devrait s'assurer que tous les engagements et les reports contractuels concernant la correction des défauts restants sont documentés et approuvés officiellement entre ISDE et le fournisseur dans le cadre d'une modification au contrat avant l'achèvement du projet, prévu pour mars 2016.

3.4 Essai du logiciel et soutien

Une stratégie d'essai complet a été établie pour soutenir le développement du logiciel. Toutefois, la portée des essais réels a été réduite et n'a pas tenu compte de la manière dont l'application logicielle complète serait utilisée.

Lorsqu'un projet comprend une configuration et une personnalisation du logiciel, il est important de disposer de ressources, d'activités et d'outils pour appuyer le processus d'essai d'AQ, afin de s'assurer que les produits livrables du logiciel sont fonctionnels et répondent aux besoins du projet. Les plans d'essais devraient intégrer les commentaires des utilisateurs dans le cycle de développement afin que les besoins réels soient pris en compte dans les essais et que le produit réponde aux besoins opérationnels. En outre, une prise en charge continue du logiciel pour les équipes de projet et les utilisateurs finaux est essentielle pour veiller à la continuité des activités pendant le développement du logiciel.

Une stratégie d'essai d'AQ pour le projet de MAS-MLC a été élaborée. Cette stratégie comprend un processus d'essais complets pour garantir que les produits livrables du logiciel ont été testés officiellement à l'aide de différents scénarios d'essai. Ces scénarios d'essai avaient pour but de confirmer si le nouveau logiciel répondait aux exigences opérationnelles.

Une équipe d'AQ a été créée et chargée de réaliser les essais, avec le soutien d'autres membres de l'équipe de projet, notamment des responsables fonctionnels et opérationnels et des experts en la matière. L'équipe d'AQ était également responsable de consigner et de gérer les résultats des essais.

En pratique, l'approche d'AQ a été modifiée par rapport aux plans et limitée aux scénarios prescrits; l'essai complet de toutes les utilisations du logiciel n'a pas été effectué. Les responsables du programme ont indiqué que cela était dû à la redéfinition des priorités en matière de ressources pour la liste des produits livrables essentiels au contrat mentionnée ci dessus. Les contraintes liées aux ressources ont également eu une incidence sur l'application de délais d'intervention du soutien pour la résolution de problèmes, qui ont été largement suspendus et limités aux problèmes considérés comme plus urgents ou risqués.

En limitant les activités d'essai, le risque que le logiciel ne réponde pas aux exigences des utilisateurs et que toutes ses fonctionnalités ne soient pas exploitées augmente. Il existe également un risque à plus long terme que les besoins en matière de soutien continu augmentent après la diffusion et la mise en œuvre, car les utilisateurs découvriront de nouveaux problèmes lors de l'utilisation opérationnelle.

Recommandation 4

La direction du projet de MAS-MLC devrait s'assurer que des essais complets sont effectués dans les domaines considérés comme étant à risque plus élevé ou d'importance opérationnelle critique pour toutes les versions futures.

3.5 Migration des données

Des plans exhaustifs de migration des données ont été élaborés et mis en œuvre et font l'objet d'un suivi régulier.

Pendant le remplacement des anciennes applications par un nouveau système, il est important d'avoir des plans et des processus adéquats, ainsi que des ressources en place pour soutenir la migration des données et les activités de nettoyage.

Des plans exhaustifs de migration des données comprenant des règles de mise en correspondance des données ont été élaborés par la direction du projet. Une approche progressive a été utilisée pour la migration des données. Chaque étape est basée sur un secteur de service lié à la stratégie de diffusion. Par exemple, seules les données relatives au secteur de service des hyperfréquences devaient être transférées de l'ancien système au nouveau système lors du déploiement de la version pilote.

L'équipe de projet a élaboré des plans de migration des données qui ont permis de tester et d'améliorer la qualité du processus de migration finale. Les registres de migration des données ont démontré que des activités de validation avaient eu lieu pour déterminer si les données avaient été correctement traduites. Les équipes de migration des données se sont réunies régulièrement pendant la durée du projet pour superviser et mener les activités de migration des données et continuent de le faire.

Avant le processus de migration pour la version pilote et la version 1 – lancement 1, les données étaient nettoyées pour faire en sorte que les anciennes données soient conformes aux exigences (c.-à-d. les règles de validation) du nouveau système. Pour atténuer le risque d'erreurs lors de la migration des données et s'assurer que l'équipe de migration et de nettoyage des données dispose de ressources suffisantes, les responsables du programme ont adopté une approche progressive pour la conversion des données.

3.6 Mise en œuvre des leçons retenues

L'équipe du projet de MAS-MLC a intégré les leçons tirées de la version pilote afin d'améliorer les versions ultérieures.

Dans le cadre de l'approche progressive du projet de MAS-MLC, la version pilote a été l'occasion pour l'équipe du projet de MAS-MLC de tirer des leçons et de les adopter. La version pilote s'est concentrée sur un secteur de service avec un groupe d'utilisateurs et de clients relativement restreint pour cerner les problèmes de déploiement nécessitant une attention particulière.

L'équipe d'audit a examiné les recommandations découlant des leçons tirées de la version pilote établies par l'équipe du projet de MAS-MLC. Toutes les recommandations ont été mises en œuvre au besoin. Lors d'entrevues avec le fournisseur, celui-ci a indiqué qu'il participait également à l'exercice portant sur les leçons tirées de la version pilote. Ces entrevues ont permis de déterminer que des avantages avaient été obtenus avec les processus de conception et de migration des données.

En juillet 2015, l'équipe de projet travaillait encore à établir les leçons préliminaires tirées de la version 1 – lancement 1.

3.7 Réponse de la direction et plan d'action

Les constatations et les recommandations de l'audit ont été présentées au sous-ministre adjoint principal du Secteur du spectre et des télécommunications (SST), au directeur général de la Direction générale des opérations de gestion du spectre, SST, et au directeur du projet de MAS MLC. La direction a accepté les constatations figurant dans le rapport et prendra des mesures pour donner suite aux recommandations d'ici le 31 décembre 2018. Notamment, la direction du SST :

  • a documenté la charte et le plan du projet et documentera le futur contrat d'entretien afin de tenir compte de l'accord conclu avec les responsables du fournisseur, selon lesquels tous les défauts prioritaires restants après la version finale seront résolues sans frais supplémentaires pour ISDE;
  • mettra à jour et finalisera les quatre plans qui abordent les besoins de l'organisation en matière de gestion du changement et sa transition vers le nouvel environnement de TI et le nouveau processus opérationnel;
  • envisage d'élaborer des paramètres de rendement précis en lien avec les processus dans un proche avenir et continuera de surveiller les résultats définis dans le plan de réalisation des résultats relatifs à la MAS et d'en rendre compte;
  • affectera des ressources supplémentaires à l'équipe responsable des essais et mettra en œuvre des essais plus rigoureux pour les secteurs à haut risque dans la version actuelle et les versions futures, ce qui devrait améliorer le processus global d'AQ.

Annexe A: Critères d'audit

Gestion du changement et préparation organisationnelle

1. Les processus de gestion du changement et les activités de préparation organisationnelle préparent efficacement les utilisateurs et les clients pour la transition vers le projet de MAS MLC.

Exigences opérationnelles et gestion de projet

2. Les exigences opérationnelles sont définies à l'aide d'une participation adéquate des intervenants et sont approuvées et présentées en fonction de l'atteinte des résultats approuvés du projet.

3. Le budget, le calendrier et la portée du projet sont gérés de façon efficace, ce qui comprend des processus de gestion des modifications apportées aux exigences et aux processus opérationnels qui leur sont associés.

Qualité du LDSM et soutien

4. Les activités d'assurance de la qualité permettent de déterminer et d'entreprendre des mesures correctives pour les défauts du logiciel.

5. Le système de MAS-MLC fournit le rendement attendu et le fournisseur offre un soutien adéquat.

Migration des données

6. La migration des données provenant des anciens systèmes permet au projet de MAS-MLC d'avoir des données exactes et complètes.

Leçons retenues

7. La mise en œuvre des leçons tirées de la version pilote et de la version 1 – lancement 1 profite aux versions ultérieures.

Annexe B: Définitions

Annexe B: Définitions
LDSM Logiciel disponible sur le marché qui peut être acheté tel quel.
Migration des données La migration des données est le processus de transfert de données entre différents systèmes informatiques ou logiciels. Elle constitue un aspect important lors de la mise en place d'un nouveau système.
Défaut On entend par « défaut » une erreur de logiciel ou une fonctionnalité manquante.
Clients externes Les clients externes comprennent les entreprises de télécommunication ainsi que les entreprises autorisées à utiliser le spectre des radiofréquences aux fins de communication.
Utilisateurs internes Les utilisateurs internes comprennent les agents responsables du spectre (et les personnes chargées des comptes-clients) qui fournissent des services aux clients externes. La plupart des utilisateurs internes sont situés dans les régions.
Responsable fonctionnel Les responsables fonctionnels sont des experts en spectre recrutés parmi les membres de la haute direction de l'administration centrale et des régions en raison de leurs connaissances du programme du spectre ainsi que des politiques, des lois et des règlements qui le régissent. Étant donné la portée considérable de certains domaines, des experts en la matière ayant des connaissances spécialisées du programme ont également été nommés pour jouer un rôle de soutien clé.
Ancien système Un ordinateur, un réseau ou un système de données plus ancien pour lequel la compatibilité est toujours maintenue et dont le remplacement est coûteux ou long.
Gestion de projet Une approche de réalisation de projet selon laquelle des techniques de gestion sont appliquées tout au long du projet en vue d'atteindre des objectifs prédéterminés.
Diffusion On entend par « diffusion » la distribution de la version finale d'une application logicielle. Elle constitue la première génération de logiciels nouveaux ou mis à niveau.
Équipe d'AQ Une équipe établie chargée d'effectuer les essais, avec le soutien d'autres membres de l'équipe de projet, notamment des responsables fonctionnels et opérationnels et des experts en la matière. Elle est aussi responsable de noter et de gérer l'état des défauts du logiciel jusqu'à leur correction.
Essais d'AQ Fait référence à un processus d'essai et à des activités pour veiller à ce que les produits livrables soient testés pour détecter les défauts et qu'ils répondent aux besoins en matière de fonctionnalité, aux exigences opérationnelles et aux besoins des utilisateurs.
Solution de rechange Un moyen de contourner les problèmes informatiques. C'est une technique qui permet à quelqu'un de remédier à un problème dans un programme ou un système informatique sans réellement résoudre le problème ou corriger le défaut.

Note de bas de page

Note de bas de page 1

Le ministre dispose de l'autorité aux termes de la Loi sur le ministère de l'Industrie, de la Loi sur la radiocommunication et du Règlement sur la radiocommunication, dans le respect des objectifs de la Loi sur les télécommunications.

Return to footnote 1 referrer