Évaluation de la modernisation des services d’hébergement (Linux/Unix)

Autorisation de reproduction

Sauf avis contraire, l’information contenue dans cette publication peut être reproduite, en tout ou en partie et par quelque moyen que ce soit, sans frais et sans autre permission de Services partagés Canada, pourvu qu’une diligence raisonnable soit exercée afin d’assurer l’exactitude de l’information reproduite, que le Titre complet de la publication soit fourni, que Services partagés Canada soit mentionné comme organisme source et que la reproduction ne soit présentée ni comme une version officielle ni comme une copie ayant été faite en collaboration avec le gouvernement du Canada ou avec son consentement. 

La reproduction et la distribution à des fins commerciales sont interdites, sauf avec la permission écrite de Services partagés Canada. Pour de plus amples renseignements, veuillez communiquer avec Services partagés Canada à publication-publication@ssc-spc.gc.ca.

© Sa Majesté le Roi du chef du Canada, représenté par le ministre responsable de Services partagés Canada, 2025. 

Évaluation de la modernisation des services d’hébergement (Linux/Unix)
No. de catalogue P118-37/2025F-PDF
ISBN  978-0-660-78198-3 

Issued also in English under the title:
Evaluation of Modernization of Hosting Services (Linux/Unix) 
Cat. No. P118-37/2025E-PDF 
ISBN  978-0-660-78197-6 

Résumé

Le Bureau de la vérification et de l’évaluation a réalisé une évaluation de la modernisation des services d’hébergement (Linux/Unix). L’évaluation a porté sur la réactivité, l’efficacité et l’efficience. Ce rapport donne un aperçu de la période allant de 2020-2021 à 2023-2024 et tient compte des données recueillies en 2024. Les services Linux/Unix ont été retenus comme le point central de l’évaluation, car ils représentent à la fois les possibilités et les défis associés à la prestation de services d’hébergement. La présente évaluation vise à orienter la prise de décisions et à déterminer l’incidence possible sur les activités futures.

Principales constations

Portée et cible d’achèvement

En 2020, Services partagés Canada (SPC) a lancé l’Initiative de modernisation des systèmes d’exploitation (IMSE) pour moderniser plus de 9 000 systèmes d’exploitation Linux/Unix de 31 organisations partenaires. La portée de cette initiative s’est élargie de 22 % au fil du temps, à mesure que les relevés d’actifs incomplets ont été corrigés. En octobre 2024, SPC avait achevé 62 % de la modernisation au titre de l’IMSE.

Bien que l’IMSE n’était pas en voie d’atteindre la cible fixée pour mars 2026, des progrès substantiels ont été réalisés. D’un point de vue technique, les progrès ont ralenti au fil du temps parce que les systèmes d’exploitation sont devenus généralement plus difficiles à mettre à niveau ou à mettre hors service, en partie parce que les efforts initiaux étaient axés sur les systèmes pouvant être traités rapidement. En outre, la technologie a évolué avec le temps, de sorte que les systèmes d’exploitation qui n’étaient pas considérés comme désuets à l’origine ont dû être mis à niveau pour demeurer à jour. Malgré ces difficultés, on s’attend à ce qu’environ 88 % de l’objectif de modernisation soit atteint d’ici mars 2026.

Incidence sur la valeur opérationnelle

Du point de vue du gouvernement du Canada (GC), l’incidence de l’objectif de modernisation non atteint sur la valeur opérationnelle n’est pas clair. En particulier, on ne sait pas comment cela pourrait avoir une incidence sur les services offerts par les partenaires aux Canadiens et sur les résultats souhaités en matière d’intendance que SPC fournit au GC. Vraisemblablement, les ministères partenaires ont été fortement incités à soutenir la modernisation des systèmes d’exploitation de leurs applications et systèmes opérationnels critiques et des autres applications et systèmes opérationnels importants dont leur ministère a besoin pour remplir son mandat. Cela suggère que les tâches de modernisation restantes pourraient avoir une valeur relativement moindre. D’un point de vue organisationnel, comparativement aux systèmes modernes, les anciens systèmes entraînent des coûts accrus de soutien par les fournisseurs, une hausse des risques liés à la sécurité, une grande complexité accrue pour la gestion et des contraintes liées à l’introduction de l’automatisation et de solutions novatrices.

Personnel de Linux/Unix à SPC

Le dévouement et le professionnalisme du personnel responsable de Linux/Unix ont constitué un facteur clé à l’appui de la modernisation des services d’hébergement Linux/Unix. Les partenaires ont fait part spontanément et de manière répétée de leurs expériences positives avec le personnel responsable de Linux/Unix. Ces expériences ont contribué à renforcer la confiance des partenaires envers SPC en tant que prestataire de services et la réputation du Ministère en matière de qualité.

Incitatifs

Parallèlement, un certain nombre de facteurs ont entravé la modernisation. Certains de ces obstacles étaient propres aux services d’hébergement Linux/Unix. Ces facteurs comprenaient l’absence de mécanismes pour inciter les partenaires à se moderniser, un manque de clarté parmi les partenaires sur les stratégies de modernisation de SPC et des lacunes dans le système de gestion des actifs et de la configuration du Ministère :

• Incitatifs : Au cours de la période d’évaluation, les partenaires manquaient de motivation pour effectuer la transition aux systèmes d’exploitation Linux/Unix modernes en temps voulu. Parallèlement, SPC n’a pas offert suffisamment d’incitatifs pour encourager les partenaires à accorder la priorité au processus de modernisation et à y participer activement.
• Clarté des plans de SPC : Tant les partenaires que les employés de SPC ont indiqué qu’ils ne comprenaient pas bien les plans stratégiques et opérationnels de SPC pour la modernisation des services d’hébergement. Les partenaires ont indiqué qu’ils avaient de la difficulté à comprendre les priorités et les calendriers de SPC pour la modernisation des services d’hébergement. Ils ont indiqué que l’absence de plans de mise en œuvre concrets et détaillés les empêchait d’harmoniser leurs plans avec les efforts de modernisation de SPC.
• Lacunes en matière d’information : Des lacunes dans le système de gestion des actifs et de la configuration de SPC ont eu une incidence sur les progrès de la modernisation. Plus précisément, SPC ne disposait pas d’outils efficaces pour le suivi des actifs et la gestion de la configuration. Cela a entravé la capacité de SPC d’atteindre les objectifs et de respecter les délais de modernisation et a eu une incidence directe sur la sécurité et la fiabilité de l’infrastructure et des services informatiques du GC.

Autres défis

De façon plus générale, des défis rencontrés à l’échelle du Ministère ont également entravé les progrès de la modernisation. Cela comprend l’inefficience du processus de traitement des demandes opérationnelles, la qualité déficiente de l’établissement des coûts et des renseignements financiers nécessaires à la prise de décisions, les difficultés en matière d’acquisition et de maintien en poste des talents et la faiblesse de la mesure du rendement des résultats.

• Processus d’intégration inefficaces : Les processus d’intégration de SPC et les outils connexes étaient lourds, ce qui a nui à la capacité de la division Linux/Unix de fournir des services en temps voulu et de manière efficace. Les lacunes dans les processus d’intégration ont été aggravées par le manque de coordination interne, ce qui a eu une incidence négative sur la capacité de SPC de gérer adéquatement la charge de travail et d’affecter les ressources.
• Outils financiers inefficaces : Les outils financiers existants de SPC et les processus connexes ont nui à sa capacité de fournir des estimations de coûts exactes et fiables. Cela a eu pour effet de décourager les partenaires de se moderniser et de nuire à la réputation de SPC en tant que prestataire de services. En l’absence d’un système intégré de gestion financière et de comptabilité analytique, SPC s’est fié aux affectations budgétaires à l’échelle des directions générales pour contrôler les coûts.
• Défis en matière de dotation : Les défis liés à l’acquisition et au maintien en poste des talents pour l’expertise relative à Linux/Unix ont eu une incidence sur la capacité de SPC d’atteindre ses objectifs opérationnels et d’offrir des solutions de modernisation. Le marché concurrentiel pour les talents spécialisés, les processus de dotation rigides et les exigences linguistiques ont fait en sorte que des postes sont restés vacants au sein de la division Linux/Unix. En novembre 2024, 21 % des postes établis dans la division Linux/Unix étaient vacants.
• Faible mesure du rendement : Enfin, le cadre fondamental de mesure du rendement pour le programme des opérations de TI des centres de données était inadéquat pour mesurer les résultats et la valeur apportée par SPC. Les principaux produits livrables n’ont pas permis de saisir adéquatement l’incidence d’un rendement excellent ou médiocre de la composante du programme Linux/Unix pour les partenaires ni de faire le suivi des avantages pour le GC de la modernisation et de l’amélioration de l’intendance.

La figure 1 présente une vue d'ensemble des différents facteurs qui ont soutenu ou entravé la modernisation.

Figure 1. Facteurs ayant favorisé ou entravé la modernisation

Recommandations

Les principales conclusions de l’évaluation ont donné lieu aux recommandations suivantes :

Recommandations no 1 (DGSH) : En collaboration avec le SCT, établir des mécanismes d’incitation pour encourager les partenaires à appuyer les objectifs de modernisation et à respecter les calendriers.

Recommandation no 2 (DGSH) : Affiner et communiquer des plans stratégiques et opérationnels détaillés pour les services d’hébergement. Cela pourrait comprendre les mesures suivantes :

• Mettre en place un processus de consultation et de collaboration avec les partenaires;
• Définir des objectifs clairs et des échéanciers réalistes;
• Fournir des détails sur les besoins en ressources pour chaque phase de modernisation afin d’aider les partenaires à planifier leur travail;
• Préciser les canaux de rétroaction pour permettre des clarifications et des ajustements.

Recommandation no 3 (DGSH) : Améliorer l’efficacité du système de gestion des actifs informatiques et de la configuration de SPC. Cela pourrait comprendre les mesures suivantes :

• Mettre à jour les bases de données de gestion des actifs et de la configuration afin de garantir la fiabilité et la mise à jour des renseignements sur les actifs et la configuration;
• Normaliser les processus de gestion des actifs et de la configuration afin de garantir l’uniformité et la fiabilité des données sur les actifs et la configuration;
• Tirer parti des outils et des processus automatisés pour réduire les erreurs humaines et fournir des mises à jour en temps réel.

Recommandation no 4 (DGOSC/DGSH) : Examiner et rationaliser les éléments des procédures d’admission afin de déterminer et d’éliminer les inefficiences. Cela pourrait comprendre les mesures suivantes :

• Établir, consigner et communiquer les processus nécessaires à la prestation de services d’hébergement Linux/Unix au moyen d’une demande opérationnelle, d’une demande de service ou d’une demande de changement;
• Veiller à ce que toutes les conditions essentielles soient réunies au moment de l’admission pour la prise de décision;
• Mettre à jour le catalogue des services afin d’améliorer la précision, la pertinence et l’accessibilité de l’information pour les partenaires;
• Améliorer l’intégration entre les outils de gestion des services (dans la mesure du possible) afin d’accroître la visibilité des demandes en cours pour les partenaires et les secteurs de service de SPC;
• Rationaliser les procédures d’admission aux services pour les partenaires et mettre Onyx à jour.

Recommandation no 5 (DGDPFA) : Améliorer la qualité et l’intégrité de l’information sur les coûts dans l’outil d’estimation des prix existants afin que SPC reçoive des fonds suffisants pour couvrir les dépenses et les frais engagés dans l’exécution des DO. Cela pourrait comprendre les mesures suivantes :

• Échantillonner les DO après l’achèvement des projets et vérifier les coûts afin de valider l’information figurant dans l’outil existant et d’améliorer les décisions de tarification;
• Améliorer le matériel de formation relatif à l’OEPE afin de réduire les erreurs commises par les utilisateurs, par exemple en communiquant les rôles et les responsabilités pour assurer l’exactitude des données saisies.

Recommandation no 6 (DGSH) : Améliorer le recrutement et le maintien en poste de spécialistes de Linux/Unix grâce à des processus de recrutement plus souples. Cela pourrait comprendre les mesures suivantes :

• Mettre en place plus fréquemment des processus de dotation spécialisés pour les postes techniques Linux/Unix;
• Examiner les exigences linguistiques pour les postes techniques Linux/Unix afin d’assurer l’harmonisation avec les exigences du poste et envisager une certaine flexibilité lorsque des mesures appropriées sont mises en place.

Recommandation no 7 (DGSH) : Mettre à jour le PIR du programme des opérations de TI des centres de données pour y ajouter des mesures de résultats pertinentes et des indicateurs de rendement adéquats, notamment des données de référence et des cibles d’amélioration. Le modèle logique doit comprendre les résultats de la prestation des services aux partenaires et les résultats en matière d’intendance pour le GC.

1. Introduction

Cette évaluation a permis d’évaluer l’adaptabilité, l’efficacité et l’efficience de la modernisation des services d’hébergement de SPC, tout particulièrement celle des services Linux et Unix. Elle visait à orienter la prise de décisions et à déterminer l’incidence possible sur les activités futures. L’évaluation a été effectuée par le BVE. Elle représente un aperçu ponctuel fondé sur les données recueillies en 2024 et porte sur la période de 2020‑2021 à 2023‑2024.

2. Contexte et progrès de la modernisation

Cette section porte sur le contexte des services d’hébergement Linux/Unix, l’initiative de modernisation des systèmes d’exploitation et les progrès réalisés dans la modernisation de Linux/Unix.

2.1 Contexte des services d’hébergement Linux/Unix

Pendant la période d’évaluation, des milliers d’applications logicielles ont été utilisées pour exploiter les systèmes servant à offrir aux Canadiens les programmes et les services du gouvernement du Canada (GC). Comme bon nombre des systèmes informatiques et des composants d’infrastructure hébergeant ces applications étaient complexes ou désuets ou n’étaient pas normalisés, ils comportaient des risques de sécurité et de fiabilité plus importants que les systèmes modernes, et leurs coûts de maintien étaient élevés.

En 2023, SPC a lancé la stratégie Réaliser des solutions numériques ensemble pour le Canada (Le numérique ensemble). L’objectif de la stratégie était de veiller à ce que les ministères disposent d’outils modernes et normalisés pour collaborer efficacement et mieux servir la population canadienne. La stratégie est axée sur quatre domaines clés de SPC : les services de connectivité, les services d’hébergement, les services numériques et les services de cybersécurité.

La stratégie comportait notamment une vision de l’évolution des services d’hébergement, qui a donné lieu à la création de la Direction générale des services d’hébergement (DGSH). La DGSH a regroupé l’ensemble des solutions d’hébergement de SPC pour que ce dernier puisse mieux répondre aux besoins des partenaires à l’aide d’une approche d’entreprise. Elle cadre avec l’orientation du GC visant à adopter une approche intelligente quant à l’infonuagique, à moderniser les applications, à réduire la dette technique et à assurer l’optimisation continue de la prestation de services. La DGSH était responsable d’exécuter le programme des opérations de technologie de l’information (TI) des centres de données, qui comprenait des éléments de programme distincts, notamment la gestion de Linux/Unix.

C’est la Division Linux/Unix qui était responsable de la gestion de Linux/Unix. L’objectif de la Division était de veiller à ce que toutes les organisations partenaires du GC disposent de solutions d’hébergement modernes, normalisées, consolidées, réactives et fiables. Pendant la période d’évaluation, la Division a géré environ 10 000 serveurs Linux/Unix prenant en charge des milliers d’applications. Bon nombre d’entre elles étaient essentielles au fonctionnement des ministères partenaires qui fournissent des services au GC ou directement à la population canadienne.

De plus amples renseignements sur les rôles et les responsabilités du Secrétariat du Conseil du Trésor (SCT), de SPC et des ministères partenaires se trouvent à l’annexe A.

2.2. Initiative de modernisation des systèmes d’exploitation

Des dizaines d’années de sous-investissement ont mené à une situation où l’infrastructure de TI du GC vieillissait plus rapidement que le rythme des réparations ou des remplacements. En avril 2020, des quelque 9 000 systèmes d’exploitation Linux/Unix connus, 5 047 n’étaient plus pris en charge par les fournisseurs ou étaient sur le point de ne plus l’être^{Footnote 1}. Les organisations partenaires avaient donc du mal à résoudre les problèmes opérationnels liés aux systèmes, ce qui augmentait les risques de temps d’arrêt et de perte de productivité. À mesure que les fournisseurs avaient cessé d’installer des mises à jour et des correctifs de sécurité, les systèmes étaient devenus plus vulnérables aux cybermenaces.

En 2020, SPC a lancé l’Initiative de modernisation des systèmes d’exploitation (IMSE) pour moderniser et normaliser les systèmes d’exploitation Linux/Unix de 31 organisations partenaires. L’IMSE était censée avoir des répercussions positives importantes dans de nombreux domaines, notamment la sécurité, la fiabilité, l’optimisation des ressources, la réalisation d’économies et la modernisation des systèmes de TI existants. Elle cadrait avec la stratégie générale de TI du GC et son programme de transformation numérique.

Les objectifs de l’IMSE étaient les suivants :

• Repérer et mettre à niveau les infrastructures obsolètes et non prises en charge hébergées dans des environnements existants;
• Réduire le nombre de types de systèmes d’exploitation Linux/Unix;
• Faire en sorte que les systèmes d’exploitation respectent les normes d’entreprise;
• Préparer les environnements des partenaires à la migration vers des centres de données d’entreprise ou le nuage.

L’équipe de l’IMSE est passée à la division Linux/Unix le 1^er mai 2024.

2.3. Progrès de la modernisation de Linux/Unix

Au départ, l’IMSE visait à moderniser plus de 9 000 systèmes d’exploitation Linux/Unix de 31 organisations partenaires d’ici 2025‑2026. Plus tard, on a constaté qu’en raison de dossiers incomplets, certains des systèmes d’exploitation pris en charge par SPC ne figuraient pas dans le répertoire initial. Ainsi, en date d’octobre 2024, le nombre total estimé de systèmes d’exploitation Linux/Unix visés par l’IMSE avait augmenté de 22 % (de 9 222 à 11 242). À cette date, SPC avait procédé à la migration ou à la mise hors service de 6 946 des systèmes d’exploitation déclarés, ce qui représente 62 % du nouveau total.

Source : Tableau de bord de l’IMSE

Malgré les difficultés, l’IMSE devrait atteindre 88 % de son objectif de modernisation d’ici la fin de l’exercice 2025‑2026. La figure 1 montre que la progression de la modernisation a ralenti à mesure que la complexité a augmenté et que la technologie a évolué.

De plus, bon nombre des premiers outils modernisés étaient des systèmes d’exploitation relativement faciles à mettre à niveau ou à mettre hors service, de sorte que le rythme de modernisation actuel est plus lent que le rythme moyen des premières années (p. ex. d’avril 2022 à mars 2023). Le ralentissement était prévisible, puisque les prochains outils à être modernisés dans le cadre de l’IMSE seraient des systèmes d’exploitation plus complexes et nécessitant des modifications importantes difficiles à reproduire ou à transférer dans de nouveaux environnements.

Avec le temps, le nombre de systèmes à moderniser pourrait aussi augmenter en raison de changements au chapitre des normes technologiques. Au fil de l’évolution de la technologie, il est possible qu’on envisage de moderniser des systèmes d’exploitation n’ayant auparavant pas été considérés comme désuets.

En ce qui concerne la valeur opérationnelle, les répercussions de l’incapacité à atteindre l’objectif, que ce soit sur les services offerts à la population canadienne par les partenaires ou sur les résultats escomptés en matière d’intendance pour le gouvernement du Canada, n’ont pas été déterminées. Vraisemblablement, les ministères partenaires ont été fortement incités à soutenir la modernisation des systèmes d’exploitation de leurs applications et systèmes opérationnels critiques et des autres applications et systèmes opérationnels importants dont leur ministère a besoin pour remplir son mandat. Cela laisse entendre que les tâches de modernisation restantes peuvent être importantes, mais qu’elles risquent d’être moins prioritaires. Pour le GC, la présence continue des systèmes d’exploitation désuets fait en sorte que les coûts de soutien par les fournisseurs, les risques de sécurité et la complexité soient plus élevés que ceux des systèmes modernes, et SPC a du mal à les gérer. De plus, elle nuit à l’automatisation et à l’innovation dans le secteur privé.

3. Constats de l’évaluation

Dans l’ensemble, l’évaluation a révélé que les partenaires apprécient sincèrement le personnel de SPC, malgré les difficultés qui ont nui à la modernisation et à l’efficience, notamment l’absence d’incitatifs pour encourager les partenaires à soutenir la modernisation ainsi que le manque de directives de la part de SPC pour aider les partenaires à se préparer et de renseignements sur la gestion des biens et de la configuration.

De façon plus générale, il y avait des défis à l’échelle ministérielle liés à l’efficience du processus de traitement des demandes opérationnelles (DO), à la qualité déficiente de l’établissement des coûts et des renseignements financiers nécessaires à la prise de décisions, aux difficultés en matière d’acquisition et de maintien en poste des talents et à la faiblesse de la mesure du rendement des résultats. La figure 3 donne un aperçu des divers facteurs ayant facilité ou entravé la modernisation.

Figure 3. Facteurs ayant facilité ou entravé la modernisation

3.1 Les partenaires apprécient le dévouement et le professionnalisme des employés de SPC

À maintes reprises, les partenaires ont déclaré par eux‑mêmes être très satisfaits de leur expérience de travail avec les employés de la Division Linux/Unix. Plus précisément, ils considéraient que la Division est une équipe solide composée de professionnels dévoués. Lors d’entrevues, ils ont fait des commentaires positifs sur le soutien exceptionnel de la Division et son attitude axée sur le client. De nombreux partenaires ont affirmé que le personnel opérationnel de la Division s’est surpassé pour répondre à leurs besoins et préoccupations. L’expérience positive des partenaires avec le personnel de SPC a contribué à accroître la satisfaction des clients ainsi que, par conséquent, leur confiance à l’égard de SPC en tant que fournisseur de services et la réputation de SPC en matière de qualité.

Figure 4. Citations de partenaires ayant eu des expériences positives avec l’équipe Linux/Unix de SPC

3.2 SPC n’avait pas de mécanismes pour inciter les partenaires à se moderniser

La modernisation et la normalisation des systèmes d’exploitation Linux/Unix ont obligé SPC à travailler en collaboration avec les organisations partenaires pour accéder à leur infrastructure et à leurs environnements informatiques. Les partenaires devaient également mettre à niveau et reconstruire leurs anciens systèmes d’information et applications pour les rendre compatibles avec les plateformes Linux/Unix les plus récentes. Plusieurs facteurs ont contribué à la faible motivation des partenaires pour cette coopération et cette modernisation. Tout d’abord, les incitatifs financiers manquaient puisque les partenaires continueraient de payer les mêmes frais de service à SPC après la transition vers des solutions plus efficaces et modernes.

Deuxièmement, même si le maintien et la protection des anciens systèmes nécessitaient généralement un soutien prolongé de la part du fournisseur, les coûts à cet égard étaient assumés par SPC et non par les partenaires, de sorte qu’il n’y avait pas d’incidence négative directe sur les coûts pour les partenaires qui continuaient d’utiliser les anciens systèmes.

Troisièmement, le risque accru lié à la sécurité de ces anciens systèmes n’a pas été perçu comme un facteur dissuasif pour les partenaires qui n’avaient pas modernisé leur système, étant donné que SPC était responsable de la prévention et de l’atténuation des risques liés à la sécurité pour les services Linux/Unix existants.

Enfin, de nombreux partenaires étaient satisfaits des systèmes existants, car les systèmes plus récents comportaient des exigences supplémentaires en matière de formation, et les partenaires croyaient généralement que l’adoption de systèmes d’exploitation plus récents nécessitait des ressources financières et humaines supplémentaires.

Les entrevues avec les partenaires et le sondage ont révélé que les partenaires (49 %) et les employés de SPC ne croyaient pas que SPC offrait suffisamment d’incitatifs pour encourager l’appui aux objectifs de modernisation, y compris les calendriers. Ces constatations sont conformes à l’analyse documentaire effectuée au cours de l’évaluation.

Les employés de SPC étaient également d’avis que le simple fait de compter sur la bonne volonté des ministères partenaires était insuffisant pour encourager la modernisation, et ils ont souligné la nécessité d’élaborer des mécanismes d’incitation efficaces pour encourager les partenaires à accorder la priorité à la modernisation et à y participer activement. Les personnes interrogées ont suggéré que cela pourrait nécessiter la participation et le soutien directs du SCT, qui, en fournissant une orientation stratégique et en exerçant une surveillance, pourrait contribuer à garantir que tout nouveau mécanisme d’incitation soit efficace et harmonisé avec les efforts de modernisation du GC.

3.3 Le manque de clarté concernant les plans stratégiques et opérationnels de SPC chez les partenaires a fait en sorte qu’il leur a été difficile d’harmoniser leurs efforts avec ceux de SPC en matière de modernisation

Au moment de la collecte des données à l’été 2024, les partenaires ont exprimé leur incertitude quant au plan stratégique et aux priorités de SPC en ce qui concerne la modernisation des services d’hébergement. Le manque de détails concrets a fait en sorte qu’il a été difficile pour les partenaires d’harmoniser leurs objectifs avec les efforts de modernisation de SPC. Au cours des entrevues, certains partenaires ont indiqué qu’ils ne comprenaient pas bien les objectifs de l’IMSE et la façon dont leur organisation pourrait en profiter directement. Dans le sondage de juillet 2024, seulement 31 % des partenaires ont convenu que les communications de SPC concernant son orientation stratégique pour les services d’hébergement Linux/Unix étaient claires.

Ce point de vue était partagé par les employés de SPC. Les personnes interrogées ont confirmé que même les membres du personnel responsable de Linux/Unix ne comprenaient pas bien le plan stratégique détaillé de SPC pour les services d’hébergement. Bien que la stratégie « Le numérique ensemble » et la feuille de route sur les services d’hébergement de SPC contenaient des énoncés de vision généraux pour un écosystème d’hébergement fiable et durable, il n’y avait pas d’orientation particulière pour une mise en œuvre efficace. Par conséquent, les employés responsables de Linux/Unix ont indiqué qu’ils avaient eu de la difficulté à expliquer aux partenaires l’incidence que la stratégie de SPC aurait sur leurs activités quotidiennes.

L’absence de détails concrets en matière de planification et de mise en œuvre a réduit davantage la capacité des partenaires à atteindre les objectifs de modernisation et à respecter les calendriers de SPC. Les partenaires ont indiqué qu’ils n’avaient pas suffisamment d’information sur le calendrier et l’enchaînement des différentes étapes de la modernisation pour la planification opérationnelle. Ils ont donné de nombreux exemples de demandes de dernière minute de SPC en prévision d’une migration ou d’une mise à niveau à venir. Ces demandes allaient de l’installation d’un logiciel antivirus à la mise à jour d’applications. Comme les partenaires n’étaient pas préparés à ces demandes, ils disposaient de peu de temps pour mettre en œuvre et tester les installations requises. Cela a entraîné le non-respect des échéances et retardé les progrès de la modernisation.

Le manque de clarté concernant les détails de la planification et de la mise en œuvre a également eu une incidence sur l’efficacité de la prestation de services. Les personnes interrogées ont déclaré qu’en raison du manque de prévoyance, la division Linux/Unix n’avait qu’une capacité limitée de fournir les ressources nécessaires pour les changements prévus. Par conséquent, la division devait répondre en permanence aux demandes des partenaires à mesure qu’elles se présentaient. Même si les services ont peut-être été fournis de façon stratégique, il y avait un manque de planification proactive permettant d’anticiper les besoins futurs et d’optimiser les ressources informatiques.

Afin de créer une approche cohérente pour les objectifs de modernisation du GC, il était nécessaire de disposer d’un plan stratégique clair et de communiquer efficacement ce plan. Les partenaires ont demandé plus d’information sur les priorités et les calendriers de modernisation de SPC afin de favoriser une meilleure coordination et une harmonisation accrue entre SPC et les ministères partenaires.

3.4 Les lacunes dans le système de gestion des actifs et de la configuration ont eu une incidence sur les progrès de la modernisation

Au cours de la période d’évaluation, SPC était responsable de la gestion d’une vaste gamme d’infrastructures informatiques gouvernementales pour lesquelles il avait besoin de renseignements exacts sur la gestion de la configuration.

3.4.1 Gestion des actifs

Afin de gérer les infrastructures informatiques de manière efficace et efficiente, SPC devait en faire le suivi et la surveillance avec précision. Un solide système de gestion des infrastructures informatiques garantirait un suivi, une gestion et une optimisation efficaces des infrastructures informatiques tout au long de leur cycle de vie.

Au cours de la période d’évaluation, le système de gestion des actifs de SPC était formé d’un ensemble d’outils et de procédures. Au sein de ce système, le suivi des actifs nécessitait la saisie manuelle de données dans des systèmes de classement, un processus laborieux, chronophage, inefficace et propice aux erreurs. De plus en plus d’erreurs se produisaient lorsque les données étaient transférées dans plusieurs systèmes de classement. Les employés responsables de Linux/Unix ont indiqué qu’environ 30 feuilles de calcul étaient utilisées à diverses étapes du processus de suivi des actifs. De plus, il n’y avait pas de mécanisme d’intégration pour gérer leurs interactions, ce qui a donné lieu à une approche segmentée et au dispersement de l’information dans l’ensemble du Ministère.

Les lacunes du système de gestion des actifs ont également eu une incidence sur la confiance des partenaires à l’égard de la prestation des services de SPC. L’étape initiale d’un projet de l’IMSE consistait à passer en revue la liste des actifs avec les partenaires afin de déterminer la portée des travaux. Ce processus a souvent révélé des listes incomplètes ou désuètes, ce qui a soulevé des préoccupations chez les partenaires quant aux capacités de suivi et de contrôle des actifs de SPC. Dans le sondage mené auprès des partenaires, seulement 32 % des répondants estimaient que la gestion des actifs de SPC pour les services d’hébergement Linux/Unix était efficace.

3.4.2 Gestion de la configuration

La gestion de la configuration était l’un des cinq processus de base pour la gestion des services de TI (GSTI). Pour réussir à moderniser les systèmes d’exploitation dans l’ensemble des ministères partenaires pendant la période de l’évaluation, SPC avait besoin de renseignements précis sur la configuration, comme les dépendances des applications, les spécifications matérielles, les détails du réseau et la correspondance entre les applications et les serveurs. Un système de gestion de la configuration robuste devrait comprendre une base de données de gestion de la configuration (BDGC) et des processus intégrés. Chaque fois qu’il y a un changement de configuration, les renseignements détaillés sur le changement doivent être consignés dans la BDGC.

Au cours de la période d’évaluation, les partenaires ont indiqué que SPC ne disposait pas de renseignements valides sur la compatibilité entre les applications et les systèmes d’exploitation des partenaires. Cela a nui à la capacité des équipes responsables de Linux/Unix d’atteindre les objectifs et de respecter les échéanciers pour la modernisation. Par exemple, au moment d’une migration prévue, une incompatibilité pouvait mettre la migration en suspens jusqu’à ce que l’application incompatible soit mise à niveau. Dans de nombreux cas, les échéances ont été prolongées pour des raisons comme la résistance des partenaires ou des contraintes liées aux ressources. Au cours des entrevues, les employés et les partenaires de SPC ont donné des exemples d’échéanciers de modernisation non respectés, les retards évoqués allant de plusieurs mois à plusieurs années.

De plus, au cours de la période d’évaluation, SPC n’avait pas suffisamment d’information sur les relations entre les applications et les serveurs. L’un des objectifs du Bureau de contrôle d’entreprise (BCE) était de maintenir un répertoire des applications critiques, mais seulement environ le tiers des applications figurant sur la liste du BCE étaient mises en correspondance avec des serveurs.

Sans information appropriée sur les relations entre les applications et les serveurs, SPC ne savait pas quelles applications du GC pouvaient être touchées en cas de panne de serveur ou de faille de sécurité. Cela aurait pu avoir des conséquences importantes pour les Canadiens qui comptaient sur les services fournis par les ministères et les organismes qui dépendent de ces applications.

Selon une analyse documentaire des pratiques exemplaires de l’industrie, les meilleurs systèmes de gestion des actifs et de la configuration s’appuient sur des outils et des logiciels d’automatisation. Ces outils et logiciels d’automatisation permettent d’améliorer la gestion de la vulnérabilité des applications grâce à un suivi précis et en temps voulu de l’information sur les actifs et la configuration. Au moment de l’évaluation, seul le répertoire pour Red Hat Linux avait été automatisé. La liste de tous les autres systèmes Linux et Unix reposait toujours sur la saisie manuelle des données.

3.5 Des lacunes dans les processus d’intégration ont nui à l’efficience de la prestation des services Linux/Unix

SPC a utilisé un certain nombre de processus différents pour gérer et traiter les demandes de nouveaux services ou de changements aux services existants. Ces processus comprenaient les demandes opérationnelles, les demandes de service et les demandes de changement.

• Demandes opérationnelles (DO) : Les partenaires et les clients peuvent soumettre un document des exigences opérationnelles (DEO) au moyen du processus d’intégration opérationnelle d’entreprise (IOE) de SPC, qui est alors devenue une DO. Le processus d’IOE comprenait plusieurs étapes, de l’intégration à la mise en œuvre.
• Demandes de service (DS) : Une DS était une demande directement attribuée au secteur de service responsable, auquel cas elle ne suivait pas le processus d’IOE.
• Demandes de changement (DC) : Une demande de changement (DC) pouvait être lancée pour modifier un service informatique. Un processus de gestion des changements était utilisé pour contrôler et gérer l’ensemble du cycle de vie de toutes les DC.

Au cours de la période d’évaluation, la majorité des activités de modernisation dans le cadre de l’IMSE ont utilisé le processus de gestion des changements. En revanche, les opérations de la division Linux/Unix ont parfois fait appel au processus d’IOE. Bien qu’il s’agisse de processus distincts sur le plan conceptuel, il y a eu des chevauchements occasionnels. Par exemple, au cours du processus de mise en œuvre d’une DC, un DEO pouvait être soumis dans le cadre du processus d’IOE pour permettre le recouvrement des coûts dans les cas où un nouveau serveur devait être acheté. Au cours des entrevues, les partenaires et les employés de SPC ont exprimé des préoccupations au sujet du rendement qui confondaient parfois les DO et les DC.

Selon les employés de SPC, l’intégration au moyen de ces différents processus était lourde et inefficace. Les documents utilisés dans ces processus pouvaient contenir des renseignements inexacts et incomplets. Par exemple, dans le cadre de la première étape du processus d’IOE, les partenaires devaient remplir un DEO. Or, étant donné que le catalogue des services de SPC contenait des renseignements périmés et insuffisants, il était souvent difficile pour un partenaire de préciser ses exigences.

Le processus d’IOE exigeait que l’équipe des responsables des relations avec les clients travaille avec les partenaires pour garantir la clarté et l’exhaustivité du document sur les besoins opérationnels (DBO). Toutefois, malgré cet effort de validation, certains DBO contenaient encore des renseignements inexacts et incomplets. Les personnes interrogées par SPC ont indiqué que, souvent, les secteurs de service Linux/Unix ne pouvaient pas répondre à une DO en raison de renseignements erronés dans le DBO, ce qui donnait lieu à de nombreux suivis et éclaircissements. Dans certains cas, la solution pour répondre à une DO a dû être remaniée et évaluée à nouveau, ce qui a entraîné des retards supplémentaires.

Les outils de GSTI de SPC, comme le BCE et Onyx, ont été utilisés pour gérer les DS et les DC. En 2022-2023, la division Linux/Unix est passée du BCE à Onyx pour la plupart des partenaires. En tant qu’outil de GSTI, Onyx était conçu pour assurer le flux de travail dans la gestion du changement en fournissant une plateforme structurée pour gérer l’ensemble du processus de changement. Il devait aider à simplifier les flux de travail en permettant aux équipes de suivre des étapes définies et de réduire au minimum les perturbations lors de la mise en œuvre des changements.

Au cours de la période d’évaluation, les employés de SPC ont signalé des lacunes dans l’utilisation d’Onyx ainsi que dans le processus de gestion des changements. Par exemple, l’une des premières étapes consistait à créer un formulaire d’intégration des charges de travail (FICT) en collaboration avec SPC et le partenaire. Les personnes interrogées ont indiqué que le FICT ne contenait parfois pas suffisamment d’information. Cela s’explique par le fait que certains partenaires n’avaient pas les connaissances techniques ou organisationnelles nécessaires pour définir les services requis. SPC a également eu de la difficulté à mobiliser les multiples secteurs de service requis pour remplir le formulaire.

L’étape d’évaluation de la DC offrait une autre occasion de garantir que les secteurs de service requis étaient mobilisés. Pour certaines DC pour lesquelles il pouvait y avoir jusqu’à huit secteurs de service, la nécessité d’obtenir l’approbation de chacun d’eux a entraîné des retards. La norme opérationnelle pour l’évaluation d’une DC était de cinq jours. Les personnes interrogées ont indiqué que cette norme n’était pas toujours respectée.

Ces lacunes pouvaient être davantage aggravées par le manque de coordination interne de SPC. Au cours des entrevues, plusieurs ministères partenaires ont indiqué que leurs billets de demande de changement créés dans Onyx avaient été attribués à la mauvaise équipe de SPC, ce qui avait nécessité de nombreux allers-retours entre les différents secteurs de service pour réattribuer et rediriger le billet et qui avait donc ralenti le temps de réponse global. Dans certains cas, lorsque la demande parvenait finalement aux secteurs de service Linux/Unix pour la mise en œuvre, il y avait un manque d’information sur l’historique de la demande. Cela signifiait que les secteurs de service Linux/Unix ne pouvaient pas facilement prendre connaissance des interactions antérieures, des changements exécutés ou des stratégies envisagées, ce qu’ils considéraient comme essentiel pour comprendre le contexte de la demande. Les employés de SPC ont indiqué que cela pouvait entraîner un dédoublement des efforts et des mesures incohérentes. Cela a également nui à la capacité de SPC de gérer la charge de travail et d’affecter les ressources adéquatement.

Un processus d’admission efficace garantirait la collecte d’informations essentielles auprès des partenaires, y compris les partenaires nouveaux et inexpérimentés. Les partenaires du SPC ont régulièrement fait part de leurs préoccupations concernant les retards causés par les différents processus d’admission. Dans le sondage mené auprès des partenaires, seuls 26 % des répondants ont estimé que le processus allant de la soumission du DEO à la mise en œuvre des services d’hébergement Linux/Unix était efficace. Les employés du SPC impliqués dans le processus d’IOE ont attribué les retards soit à un manque d’informations de la part des partenaires, soit à l’incapacité des lignes de service à coordonner leur travail de manière efficace.

Quoi qu’il en soit, les partenaires ont fait état d’un manque d’informations sur l’état d’avancement de leurs demandes. Cela les empêche de planifier et d’allouer correctement les ressources. De même, seuls 29 % des répondants estiment que les systèmes de billetterie de SPC (y compris Onyx, GSTI, etc.) pour la fourniture de services d’hébergement Linux/Unix sont efficaces.

3.6 Les outils financiers existants et les processus connexes ne permettaient pas d’assurer la précision de la tarification, le recouvrement des coûts et la transparence

En tant que fournisseur de services de TI communs du gouvernement, SPC recevait des fonds de ses partenaires pour bon nombre de ses services dans le cadre d’ententes de recouvrement des coûts. Au cours de la période d’évaluation, le modèle de recouvrement des coûts visait à soutenir la durabilité des activités de SPC et à assurer la disponibilité des fonds pour maintenir et améliorer les services offerts aux partenaires. En pratique, les activités des directions générales étaient financées à un niveau supérieur au moyen des crédits alloués à travers l’exercice d’affectation budgétaire. Cet exercice a fourni un financement initial au début de l’année et un financement subséquent tout au long du reste de l’année. Les allocations dans cet exercice étaient basées sur des prévisions de recouvrement des coûts développées en collaboration avec les secteurs de service et la DGDPFA.

Au cours de la période d’évaluation, l’outil d’estimation des prix d’entreprise (OEPE) était le principal outil utilisé par SPC pour établir le prix des ententes individuelles de recouvrement des coûts conclues avec les partenaires pour les services Linux/Unix et des demandes opérationnelles (DO) particulières. Cette application basée sur Excel et prenant en charge les macros était utilisée pour créer des estimations des coûts à partir des principaux coûts directs (p. ex. les serveurs et les licences), de certains coûts indirects (p. ex. les salaires) et des coûts permanents de fonctionnement et d’entretien (p. ex. le soutien et la gestion des correctifs).

L’estimation des coûts relatifs aux services Linux/Unix était difficile. Malgré des efforts soutenus pour mettre à jour et suivre les coûts directs pertinents, la plupart des autres renseignements sur les coûts étaient incomplets. Un grand nombre de processus et d’étapes liés à la prestation des services Linux/Unix étaient également complexes. Il était donc difficile d’établir des estimations des coûts précises, même si tous les coûts directs et indirects étaient pris en compte.

Les responsables des relations avec les clients et les autres utilisateurs de SPC produisaient des estimations des prix personnalisées pour répondre aux besoins uniques des clients. Le personnel de SPC a indiqué que cette option dans l’outil était lourde et susceptible d’entraîner des erreurs de la part des utilisateurs.

Le recours à des feuilles de calcul comme principal outil d’estimation des coûts des projets causait plusieurs difficultés ayant une incidence sur la précision et la fiabilité. Plus précisément, l’OEPE n’était pas doté de fonctionnalités avancées permettant de saisir avec précision les nuances des programmes informatiques complexes et de générer des estimations précises des prix. Par exemple, les services d’hébergement touchaient souvent plusieurs secteurs de service, comme Linux/Unix, Windows et la virtualisation. Toutefois, il a été signalé que l’OEPE ne permettait pas de répartir facilement les coûts entre plusieurs centres de coûts dans une même estimation.

De plus, certains types de services d’hébergement étaient affectés par défaut à un centre de coûts particulier dans l’outil. Si l’utilisation d’un centre de coûts par défaut permettait de rationaliser les processus financiers dans certains cas, elle augmentait également le risque d’erreur humaine. Comme ce champ par défaut devait être modifié manuellement pour chaque estimation, il y avait un risque que l’étape soit sautée et que la qualité des données recueillies s’en trouve affectée.

Les mises à jour peu fréquentes ont également nui à l’efficacité de l’outil. Plus précisément, la mise à jour complète de l’information sur les coûts contenue dans l’OEPE n’était effectuée que tous les deux ans. Entre-temps, les utilisateurs devaient faire des demandes ponctuelles pour les mises à jour hors cycle. Dans l’ensemble, le mode d’actualisation des prix présentait des inconvénients dans un environnement technologique où les activités évoluaient rapidement et où les coûts pouvaient fluctuer de manière importante. Les mises à jour peu fréquentes ne permettaient pas de saisir en temps réel les variations des coûts causées par des facteurs externes tels que l’inflation, les problèmes liés à la chaîne d’approvisionnement ou l’évolution de la demande. Par conséquent, les estimations des coûts devenaient obsolètes après chaque mise à jour. Si un changement de prix important survenait peu après la mise à jour, il pouvait n’être pris en compte que deux ans plus tard, à la prochaine mise à jour prévue. La sous-estimation des coûts faisait en sorte que SPC pouvait charger aux partenaires des sommes insuffisantes, ce qui entraînait des déficits budgétaires lorsque les frais engagés n’étaient pas entièrement recouvrés.

L’absence d’une étape de validation des coûts après la prestation des services constituait une autre lacune. Si l’estimation des coûts au cours des premières étapes est cruciale pour la gestion des ressources, la validation de ces estimations après la prestation des services est tout aussi importante pour assurer l’exactitude des données. Comme les coûts n’étaient pas validés après la prestation des services, il n’y avait aucune confirmation que le bon montant avait été facturé aux partenaires.

La tarification et le recouvrement des coûts représentaient un processus d’affaires intégré qui reposait sur un modèle décentralisé auquel participaient plusieurs directions générales. Ce processus, combiné à l’utilisation de l’outil, a conduit à des divergences significatives. La division responsable de Linux/Unix a pris l’initiative de mettre en place une petite équipe chargée d’examiner et de corriger certains problèmes liés à l’établissement des coûts. Elle a apporté des corrections dans l’OEPE et dans le Système de suivi de l’intégration opérationnelle (SSIO).

Au moment de l’évaluation, la division Linux/Unix avait noté des erreurs de saisie de données et des coûts manquants correspondant à environ 12 millions de dollars depuis 2020 pour ses deux principaux partenaires.

Ces deux partenaires représentaient 29 % du portefeuille d’activités de la division. Bien que l’équipe ait travaillé avec son conseiller en gestion financière pour corriger les problèmes, ces données globales n’ont pas été validées de manière indépendante par la DGDPFA.

Exemples d’erreurs corrigées :

• Certains serveurs n’étaient pas indiqués dans l’OEPE et n’avaient donc jamais été facturés au partenaire;
• Certains coûts permanents, comme ceux relatifs au soutien, ne figuraient pas dans l’OEPE;
• Les mauvais centres de coûts étaient utilisés entre la division Linux/Unix et d’autres secteurs de service;
• De l’information contradictoire sur les coûts avait été saisie dans les différents systèmes (p. ex. le coût dans l’OEPE différait de celui dans le SSIO).

Le personnel de la division Linux/Unix estimait que les efforts déployés en vue de corriger les erreurs relatives aux centres de coûts avaient des répercussions sur les fonds disponibles pour la division. Même s’il fallait peut-être saisir l’information sur les centres de coûts dans l’OEPE, ces données n’étaient pas utilisées. Les affectations budgétaires étaient plutôt effectuées à un niveau supérieur et n’étaient pas directement liées aux montants réels des DO versés aux différents centres de coûts.

Au cours de la période d’évaluation, la DGDPFA était chargée d’assurer l’intégrité de l’OEPE. Elle a fourni des instructions écrites sur son utilisation et des vidéos de formation à l’intention des utilisateurs. Plus récemment, elle a demandé à tous les gestionnaires de SPC ayant des pouvoirs délégués de suivre une formation obligatoire, car les responsables des centres de coûts sont tenus de s’assurer que leurs équipes saisissent correctement les données relatives aux dépenses.

Il est important de noter que le système de comptabilité financière de SPC (Sigma) n’était pas relié aux DO individuelles au cours de la période d’évaluation. Il était donc difficile de valider les coûts après la prestation des services.

Répercussions sur la modernisation des services d’hébergement

Les partenaires ont indiqué qu’en raison des restrictions budgétaires, la disponibilité du financement a souvent nui à leur capacité d’aller de l’avant avec les initiatives de modernisation de SPC. De nombreux partenaires devaient composer avec une dette technique, une augmentation des coûts et une réduction du financement pour leurs systèmes d’information et leur portefeuille d’applications. Ainsi, les nouveaux investissements dans la modernisation des systèmes d’exploitation Linux/Unix exerçaient des pressions supplémentaires sur des budgets déjà serrés.

Dans ce contexte, certains partenaires ont signalé que les prix relatifs à Linux/Unix semblaient élevés. D’autres ont reconnu que le coût élevé des services de SPC reflétait les niveaux élevés de sécurité exigés pour répondre aux normes du gouvernement du Canada.

Quoi qu’il en soit, les partenaires ont signalé à plusieurs reprises et de manière indépendante que les estimations des coûts fournies par SPC pour les services relatifs à Linux/Unix n’étaient pas uniformes et qu’elles manquaient de précision. Le sondage mené auprès des partenaires l’a confirmé. Plus précisément, seuls 13 % des répondants étaient d’accord pour dire que les prix exigés par SPC pour les services d’hébergement Linux/Unix étaient transparents. Les partenaires ont également indiqué que le manque de transparence avait contribué à leur réticence à consacrer des efforts et des ressources à l’atteinte des objectifs de modernisation de SPC.

Répercussions sur l’amélioration continue

Au cours de la période d’évaluation, le système de comptabilité financière (Sigma) n’était pas intégré au SSIO et n’incluait pas les coûts associés à l’exécution des DO individuelles. SPC s’appuyait principalement sur les affectations budgétaires au niveau des directions générales (selon les crédits alloués et les prévisions des recettes annuelles provenant du recouvrement des coûts) pour contrôler les coûts au sein du ministère.

À l’avenir, la validation et l’analyse des coûts seront probablement de plus en plus importantes aux fins d’amélioration continue et de limitation des coûts. En cette période de restriction des dépenses et de budgets fixes, les cadres et les gestionnaires de SPC seront probablement de plus en plus amenés à revoir leurs opérations pour y repérer les lacunes et à trouver des façons de réaliser des économies supplémentaires au niveau des centres de coûts.

Malheureusement, étant donné les outils actuels et l’information disponible sur les coûts, les cadres et les gestionnaires, au niveau des centres de coûts, ne sont pas en mesure :

• d’effectuer des analyses de sensibilité (p. ex. déterminer les répercussions financières de la modification des coûts de soutien pour les systèmes d’exploitation vieillissants);
• de déterminer les domaines précis dans lesquels des économies pourraient être réalisées (p. ex. déterminer les dépenses relatives aux coûts de soutien pour les systèmes d’exploitation non normalisés);
• de soutenir la planification à l’échelle des divisions (p. ex. les répercussions financières du passage à une nouvelle version d’un système d’exploitation);
• de comprendre les répercussions financières des situations inattendues (p. ex. une panne imprévue ou une mise à jour qui a échoué);
• d’appuyer les leçons retenues du suivi des dépenses d’une année à l’autre.

3.7 Il y avait d’importants obstacles liés à l’acquisition et au maintien en poste des talents pour l’expertise relative à Linux/Unix

Selon la Stratégie du Gouvernement numérique du Canada de 2021, le GC a eu de la difficulté à recruter et à maintenir en poste des talents numériques qualifiés pour offrir les services nécessaires. Le plan d’activités intégré 2024-2025 de SPC a également souligné l’importance de la capacité et du maintien en poste de la main-d’œuvre. À titre de ministère responsable de la prestation de services numériques au GC, SPC a été confronté à des difficultés constantes pour recruter et conserver le personnel et les compétences nécessaires à l’atteinte de ses objectifs opérationnels.

Ces défis sont particulièrement importants pour l’expertise relative à Linux/Unix. Au cours de la période d’évaluation, l’expertise relative à Linux/Unix était considérée comme un talent hautement spécialisé et niché, aucun programme officiel d’études postsecondaires ne produisant une nouvelle génération d’experts en matière de Linux/Unix. La plupart des professionnels de Linux/Unix à SPC ont acquis leur expertise grâce à une série d’expériences professionnelles pertinentes ainsi qu’à des cours de formation offerts par des fournisseurs et à des programmes de certification de l’industrie. Il fallait souvent de nombreuses années pour devenir compétent.

Durant la période d’évaluation, le marché de l’expertise relative à Linux/Unix était très concurrentiel. Les entités du secteur public comme SPC ont dû rivaliser avec les employeurs du secteur privé pour attirer et conserver ce personnel. SPC était en concurrence directe avec des industries, comme le secteur bancaire, qui étaient en mesure d’offrir des régimes de rémunération plus concurrentiels.

L’obligation de travailler sur place ou de manière hybride, qui contraste avec la flexibilité du télétravail offerte par de nombreuses entités du secteur privé au cours de la période d’évaluation, a ajouté aux défis de SPC en ce qui concerne la dotation.

En raison de ces difficultés relatives à la dotation et au maintien en poste, de nombreux postes au sein de la division Linux/Unix et du groupe de l’IMSE sont demeurés vacants. En novembre 2024, parmi les 296 postes établis dans l’organigramme de la division Linux/Unix, 61 étaient vacants, ce qui représente 21 % de l’effectif.

Pour atténuer les difficultés à attirer et à maintenir en poste des employés possédant une expertise technique Linux/Unix, SPC s’est largement appuyé sur des consultants externes pour la prestation des services^{Footnote 2}. Bien qu’elle ait été efficace à court terme, cette approche ne constituait pas une solution durable pour le renforcement des capacités internes à long terme.

En outre, les gestionnaires d’embauche de SPC ont indiqué que les processus de dotation existants étaient trop génériques pour répondre efficacement aux exigences particulières des rôles techniques liés à Linux/Unix. La description générique du poste et l’énoncé des critères de mérite utilisés pour pourvoir les postes techniques Linux/Unix exigeaient une vaste expérience en TI, mais ils ne mettaient pas en évidence Linux/Unix en tant que compétence principale. De plus, il n’y avait pas non plus de condition quant à l’étendue de l’expérience requise en matière d’opérations Linux/Unix. De ce fait, les critères de mérite ne permettaient pas de filtrer les candidats ayant le niveau de compétence requis pour réaliser des opérations complexes en matière de Linux/Unix au sein de SPC.

Enfin, les gestionnaires d’embauche de SPC ont exprimé des préoccupations concernant les exigences en matière de bilinguisme pour les postes Linux/Unix. Ils reconnaissaient l’importance de la capacité bilingue pour les postes nécessitant une interaction avec la clientèle, mais étaient d’avis que l’application de la politique par le Ministère à tous les postes était peut-être trop rigide. Plus précisément, le travail réel pour certains postes sans fonction de supervision comprenait des interactions très limitées avec les partenaires. L’application d’une approche universelle a peut-être involontairement restreint le bassin de candidats potentiels possédant les qualifications techniques appropriées.

Dans le cadre de l’évaluation, une étude indépendante sur le bilinguisme a été commandée pour examiner les postes de TI pour les services Linux/Unix, dont les postes de conseiller technique IT-01, IT-02, IT-03 et de chef d’équipe IT-03. L’étude portait sur les descriptions de poste, les organigrammes, l’emplacement des postes, les exigences linguistiques, les descriptions des responsabilités de supervision, la législation applicable, les documents stratégiques du Conseil du Trésor, les publications du Commissariat aux langues officielles et les résultats du Sondage auprès des fonctionnaires fédéraux. L’étude comportait des entrevues avec les gestionnaires d’embauche et les représentants des langues officielles de SPC.

Elle a confirmé que SPC avait très bien réussi à répondre aux attentes du SCT, soit qu’environ 30 % des postes soient bilingues. Parmi les 254 postes de TI pour les services Linux/Unix, 43 % avaient un profil bilingue.

L’étude a également confirmé les difficultés à attirer et à conserver l’expertise relative à Linux/Unix au sein de SPC en raison des exigences en matière de bilinguisme. Ces difficultés ont eu une incidence particulière sur la dotation et le maintien en poste des conseillers techniques IT-03.

Au cours de la période d’évaluation, le poste de conseiller technique IT-03 a joué un rôle essentiel dans la prestation des services et la modernisation des systèmes d’exploitation. En novembre 2024, ces postes représentaient 34 % de l’ensemble des postes de TI pour les services Linux/Unix. Comme le montre le tableau 1,33 % des 85 postes de conseillers techniques IT-03 pour Linux/Unix avaient un profil bilingue. Les postes bilingues présentaient également des taux élevés de postes vacants. Parmi les postes BBB, 33 % étaient vacants. Pour les postes nécessitant un profil CBC, 40 % étaient vacants^{Footnote 3}.

Selon l’étude sur le bilinguisme, les postes de conseiller technique IT-03 ne comportaient pas de responsabilités de supervision, et leurs tâches ne comportaient aucune interaction ou comportaient peu d’interaction avec les clients. Cela signifie qu’ils avaient très peu de demandes liées aux « services centraux ».

L’étude a mis en évidence la nécessité pour SPC d’adopter des processus de dotation plus souples afin de répondre aux besoins de dotation et de maintien en poste des spécialistes en matière de Linux/Unix. En particulier, SPC pourrait vouloir consulter d’autres organisations fédérales qui sont en mesure d’avoir des exigences linguistiques souples. Dans certaines circonstances, des organisations comme l’Agence spatiale canadienne, Santé Canada et Ressources naturelles Canada ont pu obtenir des dérogations pour leurs exigences linguistiques et l’utilisation de processus de dotation génériques.

3.8 Le cadre de mesure du rendement existant était inadéquat pour mesurer l’incidence du rendement

Conformément à la Politique sur les résultats du Conseil du Trésor, un profil d’information sur le rendement (PIR) a été établi et tenu à jour pour le programme des opérations de TI des centres de données. Il décrivait les extrants, les résultats et les indicateurs de rendement du programme dans son ensemble.

Selon la Politique, les résultats du programme sont des changements ou des conséquences attribuables aux produits ou services directs du programme. En revanche, les extrants du programme sont les services et les produits directs découlant des activités du programme. Les extrants relèvent généralement du contrôle de l’organisation elle‑même.

Pendant la période d’évaluation, le PIR du programme des opérations de TI des centres de données a permis de déterminer le résultat immédiat et le résultat intermédiaire du programme :

• Résultat immédiat : Les services de centres de données sont offerts pour faciliter l’utilisation des applications et des services essentiels et non essentiels des partenaires et des clients.
• Résultat intermédiaire : Les solutions et les normes d’entreprise sont adoptées par les partenaires et les clients.

Le résultat immédiat (c.‑à‑d. offrir les services de centres de données) découle directement des activités du programme. Il ne consiste pas en une mesure de l’incidence des services de centres de données de SPC sur les organisations partenaires. Par définition, il s’agit donc d’un extrant, plutôt que d’un résultat.

Les indicateurs de rendement suivants, définis dans le cadre du PIR du programme des opérations de TI des centres de données, serviront à mesurer les deux résultats :

• Pourcentage d’ordinateurs centraux migrés des anciens centres de données vers les centres de données d’entreprise à l’état final;
• Temps moyen de rétablissement des services des ordinateurs centraux après un incident critique;
• Pourcentage de temps où l’infrastructure des services d’ordinateur central est disponible;
• Pourcentage de temps où l’infrastructure de calcul de haute performance intégré est disponible;
• Pourcentage de temps où l’infrastructure de stockage est disponible;
• Pourcentage de temps où l’infrastructure des services de fichiers est disponible;
• Satisfaction de la clientèle à l’égard des services de centres de données.

Les indicateurs portaient sur la disponibilité des services et les pourcentages de migration. Les données recueillies pour les indicateurs n’ont permis de mieux comprendre ni la qualité du processus de migration, ni la nature des incidents, ni les gains de rendement et d’efficiences découlant de la migration. Les indicateurs n’étaient pas assez rigoureux pour mesurer suffisamment les résultats du programme. Tout au plus, ils ont permis de mesurer les extrants.

La Division Linux/Unix utilisait ses propres indicateurs de rendement non liés au PIR. Ceux-ci mesuraient le pourcentage de temps où les systèmes d’exploitation étaient disponibles et les progrès réalisés dans l’installation des dernières versions de Linux/Unix chez les partenaires. Encore une fois, ils n’étaient pas assez rigoureux pour mesurer les résultats et l’incidence de la qualité des services fournis par SPC.

Au mieux, la Division utilisait la satisfaction de la clientèle comme indicateur pour mesurer les résultats découlant de ses services. Cependant, d’un point de vue conceptuel, il n’était pas judicieux d’utiliser la satisfaction de la clientèle pour mesurer les résultats. Le taux de satisfaction est une donnée qui varie en fonction de nombreux facteurs, notamment les perceptions et les attentes des clients. Il peut également correspondre à la satisfaction à l’égard des extrants plutôt que des résultats. Par conséquent, la satisfaction des clients n’a pas directement permis d’évaluer l’incidence réelle du rendement, bon ou mauvais, de l’élément de programme Linux/Unix.

Il aurait été préférable d’évaluer la manière dont la Division Linux/Unix a aidé les DPI des partenaires et clients à remplir leur mandat^{Footnote 4}. Le PIR ne comprenait aucun critère pour mesurer la façon dont les services d’hébergement ont contribué à l’obtention des résultats organisationnels et des résultats en matière d’intendance du GC. Dans tous les cas, il faut avoir défini des données de référence en matière de rendement et des cibles d’amélioration.

Ces types de difficultés liées à la mesure du rendement ont touché tous les PIR de SPC.

4. Conclusions et recommandations

L’évaluation a permis de cerner les facteurs qui appuyaient et entravaient la modernisation des services d’hébergement.

Les partenaires ont grandement apprécié le service exceptionnel qu’ils ont reçu de la part des membres de l’équipe Linux/Unix. Cette satisfaction a contribué à renforcer la confiance des partenaires envers SPC en tant que prestataire de services et la réputation du ministère pour ce qui est de la qualité de ses services.

Parallèlement, des lacunes et des inefficiences au sein de SPC ont entravé les efforts de modernisation.

Certains de ces obstacles étaient propres aux services d’hébergement. Tout d’abord, la motivation des partenaires a été influencée par l’absence de mécanismes d’incitation, ce qui a eu une incidence sur l’atteinte des objectifs et le respect des calendriers de modernisation. Deuxièmement, SPC ne disposait pas de plans stratégiques et opérationnels clairs et bien définis en matière de modernisation pour communiquer efficacement ses objectifs et harmoniser les efforts de modernisation. Il était donc difficile pour les partenaires de planifier le processus de modernisation et d’y participer. De plus, des lacunes dans le système de gestion des actifs et de la configuration ont entravé la capacité de SPC de mettre en œuvre efficacement la modernisation, sans compter l’incidence directe sur la sécurité et la fiabilité de l’infrastructure et des services informatiques du GC.

Il y avait aussi des défis à l’échelle du Ministère associés aux outils et processus inefficaces. Les lacunes dans les processus d’intégration de SPC ont entraîné des retards dans la modernisation et ont eu une incidence négative sur la capacité de la division Linux/Unix de fournir des services d’hébergement. En outre, les outils financiers existants de SPC étaient inefficaces pour soutenir une évaluation précise des coûts, le recouvrement des coûts et la transparence, ce qui a entraîné une baisse de la satisfaction des partenaires et un impact négatif sur la réputation de SPC en tant que prestataire de services. En ce qui concerne la dotation, l’utilisation de processus génériques et la façon d’appliquer les exigences linguistiques ont empêché SPC d’attirer et de conserver efficacement des professionnels qualifiés possédant des compétences spécialisées en matière de Linux/Unix. Enfin, le document de mesure du rendement pour le programme des opérations de TI des centres de données de SPC contenait des résultats et des indicateurs de rendement mal définis. Il n’a pas permis de saisir adéquatement les répercussions d’un rendement excellent ou médiocre de la composante du programme Linux/Unix pour les partenaires ni de faire le suivi des avantages de la modernisation pour le GC.

Recommandations no 1 (DGSH) : En collaboration avec le SCT, établir des mécanismes d’incitation pour encourager les partenaires à appuyer les objectifs de modernisation et à respecter les calendriers.

Recommandation no 2 (DGSH) : Affiner et communiquer des plans stratégiques et opérationnels détaillés pour les services d’hébergement. Cela pourrait comprendre les mesures suivantes :

• Mettre en place un processus de consultation et de collaboration avec les partenaires;
• Définir des objectifs clairs et des échéanciers réalistes;
• Fournir des détails sur les besoins en ressources pour chaque phase de modernisation afin d’aider les partenaires à planifier leur travail;
• Préciser les canaux de rétroaction pour permettre des clarifications et des ajustements.

Recommandation no 3 (DGSH) : Améliorer l’efficacité du système de gestion des actifs informatiques et de la configuration de SPC. Cela pourrait comprendre les mesures suivantes :

• Mettre à jour les bases de données de gestion des actifs et de la configuration afin de garantir la fiabilité et la mise à jour des renseignements sur les actifs et la configuration;
• Normaliser les processus de gestion des actifs et de la configuration afin de garantir l’uniformité et la fiabilité des données sur les actifs et la configuration;
• Tirer parti des outils et des processus automatisés pour réduire les erreurs humaines et fournir des mises à jour en temps réel.

Recommandation no 4 (DGOSC/DGSH) : Examiner et rationaliser les éléments des procédures d’admission afin de déterminer et d’éliminer les inefficiences. Cela pourrait comprendre les mesures suivantes :

• Établir, consigner et communiquer les processus nécessaires à la prestation de services d’hébergement Linux/Unix au moyen d’une demande opérationnelle, d’une demande de service ou d’une demande de changement;
• Veiller à ce que toutes les conditions essentielles soient réunies au moment de l’admission pour la prise de décision;
• Mettre à jour le catalogue des services afin d’améliorer la précision, la pertinence et l’accessibilité de l’information pour les partenaires;
• Améliorer l’intégration entre les outils de gestion des services (dans la mesure du possible) afin d’accroître la visibilité des demandes en cours pour les partenaires et les secteurs de service de SPC;
• Rationaliser les procédures d’admission aux services pour les partenaires et mettre Onyx à jour.

Recommandation no 5 (DGDPFA) : Améliorer la qualité et l’intégrité de l’information sur les coûts dans l’outil d’estimation des prix existants afin que SPC reçoive des fonds suffisants pour couvrir les dépenses et les frais engagés dans l’exécution des DO. Cela pourrait comprendre les mesures suivantes :

• Échantillonner les DO après l’achèvement des projets et vérifier les coûts afin de valider l’information figurant dans l’outil existant et d’améliorer les décisions de tarification;
• Améliorer le matériel de formation relatif à l’OEPE afin de réduire les erreurs commises par les utilisateurs, par exemple en communiquant les rôles et les responsabilités pour assurer l’exactitude des données saisies.

Recommandation no 6 (DGSH) : Améliorer le recrutement et le maintien en poste de spécialistes de Linux/Unix grâce à des processus de recrutement plus souples. Cela pourrait comprendre les mesures suivantes :

• Mettre en place plus fréquemment des processus de dotation spécialisés pour les postes techniques Linux/Unix;
• Examiner les exigences linguistiques pour les postes techniques Linux/Unix afin d’assurer l’harmonisation avec les exigences du poste et envisager une certaine flexibilité lorsque des mesures appropriées sont mises en place.

Recommandation no 7 (DGSH) : Mettre à jour le PIR du programme des opérations de TI des centres de données pour y ajouter des mesures de résultats pertinentes et des indicateurs de rendement adéquats, notamment des données de référence et des cibles d’amélioration. Le modèle logique doit comprendre les résultats de la prestation des services aux partenaires et les résultats en matière d’intendance pour le GC.

Annexe A : Renseignements supplémentaires sur les services d’hébergement Linux/Unix de SPC

Rôles et responsabilités des intervenants clés

De nombreux intervenants, notamment le SCT et des ministères partenaires, ont joué un rôle important dans la prestation des services d’hébergement de SPC. Le SCT était responsable d’établir les orientations stratégiques concernant les services d’hébergement ainsi que d’assurer le respect des politiques. Les ministères partenaires devaient veiller à ce que leurs décisions au sujet de l’hébergement cadrent avec l’orientation du SCT et collaborer avec SPC pour optimiser l’hébergement dans l’ensemble du GC. Tout particulièrement, ils devaient vérifier que leurs applications étaient modernisées, durables et prêtes à être hébergées avant de présenter une demande à SPC.

La Stratégie d’hébergement d’applications 2024 publiée par le SCT décrit les rôles et les responsabilités du SCT, de SPC et des ministères partenaires.

Annexe B : Méthodes

1. Objectif et portée

L’évaluation a été effectuée par le BVE. Elle représente un aperçu ponctuel fondé sur les données recueillies en 2024 et porte sur la période de 2020‑2021 à 2023‑2024. L’objectif du BVE est d’orienter la prise de décisions en évaluant de manière neutre l’adaptabilité, l’efficacité et l’efficience de la modernisation des services d’hébergement Linux/Unix de SPC. L’évaluation portait sur les services Linux/Unix, car ils sont considérés comme une étude de cas utile pour tous les services d’hébergement de SPC.

Au départ, l’évaluation servait à répondre à trois questions, lesquelles ont été déterminées à la suite des discussions initiales avec l’équipe de gestion des programmes et des entrevues de définition de la portée.

• Réactivité : Dans quelle mesure SPC est-il parvenu à faire progresser l’approche d’entreprise pour ce qui est des services d’hébergement Linux/Unix?
• Efficacité : Dans quelle mesure les services d’hébergement Linux/Unix ont-ils permis d’atteindre les résultats escomptés?
• Efficience : Quelles sont les possibilités d’amélioration de la efficience?

2. Méthodes de collecte de données

Pour répondre aux questions d’évaluation définies ci-dessus, l’équipe d’évaluation a utilisé différentes méthodes. En utilisant la triangulation des données, l’équipe a recoupé les éléments de preuve suivants afin de cerner, d’analyser et de valider les résultats.

Analyse documentaire

Deux analyses documentaires ont été réalisées pour examiner les thèmes pertinents des services Linux/Unix, notamment les tendances de l’industrie, les pratiques exemplaires et les mesures de rendement des solutions de milieu de gamme Linux/Unix. Les renseignements tirés des analyses documentaires ont servi de base à la constitution d’un échantillon pour comparer les administrations (voir la section ci‑dessous).

Examen des documents

L’équipe d’évaluation a rassemblé des renseignements provenant de diverses sources documentaires relatives aux services Linux/Unix de SPC, notamment :

• des présentations aux conseils de gouvernance de SPC (p. ex. Conseil exécutif de surveillance; Conseil de gestion interne, des investissements et des finances; Conseil des opérations et des services);
• des documents et des présentations de programme;
• d’autres documents relatifs à la modernisation des services d’hébergement Linux/Unix.
• InfoBase du GC – Gouvernement du Canada
• Dépôt de données d’entreprise
• Données administratives fournies par la DGSH

Cette analyse a permis d’acquérir des connaissances sur les services Linux/Unix de SPC et leur évolution dans le temps, d’orienter la mise au point d’un modèle logique des services Linux/Unix pour faciliter l’évaluation et de concevoir la matrice d’évaluation. Pour veiller à ce que les recommandations soient à jour et pertinentes, l’examen des documents a été mis à jour régulièrement jusqu’en novembre 2024.

Analyse des données administratives

L’équipe d’évaluation a utilisé les sources de données suivantes pour effectuer une analyse des données administratives des exercices de 2019‑2020 à 2023‑2024 :

Cette analyse a permis de mieux comprendre les problèmes et les tendances liés aux mesures de la prestation des services; l’évolution des dépenses, des revenus et du financement des programmes; et le point de vue des partenaires sur la modernisation des services d’hébergement de SPC.

Entrevues avec les principaux répondants

L’équipe d’évaluation a effectué des entrevues semi-structurées auprès de différents groupes d’intervenants pour recueillir de l’information sur les opinions et les expériences, des explications et des renseignements factuels concernant les services Linux/Unix de SPC. Les intervenants en question ont été sélectionnés en vue de maximiser la diversité et la représentativité. Au total, 41 entrevues ont été réalisées, dont 25 entrevues internes avec des intervenants de SPC et 16 entrevues externes avec des organisations partenaires.

Comparaison entre les administrations

L’équipe d’évaluation a demandé qu’une étude soit réalisée pour examiner les expériences, les pratiques exemplaires et les leçons apprises de 11 administrations internationales et nationales. L’étude a permis de comparer différentes administrations pour comprendre leurs stratégies de gestion et de prestation des solutions d’hébergement. L’accent a notamment été mis sur les perspectives internationales et nationales liées à la prestation de solutions d’hébergement au moyen d’une approche d’entreprise.

Examen du bilinguisme

L’équipe d’évaluation a demandé qu’une étude soit réalisée pour examiner les exigences linguistiques des postes du groupe IT au sein de la Division Linux/Unix. L’étude a servi à examiner les documents pertinents en matière de ressources humaines, notamment les descriptions d’emploi, les organigrammes, ainsi que les documents de politique connexes du CT, pour déterminer si les exigences linguistiques des postes cadraient avec leurs fonctions. Des entrevues ont également été menées auprès de représentants de la Division Linux/Unix et de l’Unité des langues officielles, qui fait partie des Services des ressources humaines de SPC. L’étude a aussi permis de cerner les attentes professionnelles actuelles et les besoins possibles en matière de ressources humaines pouvant découler des attentes maintenant et à l’avenir.

Sondage auprès des clients

L’équipe d’évaluation a mené un sondage en ligne pour connaître les opinions des partenaires sur la modernisation des services Linux/Unix. Le sondage a permis de recueillir des données auprès d’organisations partenaires de mai à juin 2024. Des 31 organisations partenaires invitées à participer au sondage, 26 ont répondu, ce qui représente un taux de réponse de 84 %.

Annexe C : Liste des sigles

DBO

Document sur les besoins opérationnels

DGDPFA

Direction générale du dirigeant principal des finances et de l’approvisionnement

DGSH

Direction générale des services d’hébergement

DO

Demande opérationnelle

DPI

Dirigeant principal de l’information

GC

Gouvernement du Canada

GSTI

Gestion des services de technologie de l’information

IMSE

Initiative de modernisation des systèmes d’exploitation

IRSC

Initiative de rétroaction sur la satisfaction de la clientèle

OEPE

Outil d’estimation des prix d’entreprise

PIR

Profil d’information sur le rendement

SCT

Secrétariat du Conseil du Trésor du Canada

SPC

Services partagés Canada

TI

Technologie de l’information