Modèle de prestation de la solution de TI cible

Remarque 1 : la source faisant autorité et la dernière version de la stratégie sont disponibles sur le réseau interne d’EDSC

Remarque 2 : cette page renferme des liens vers des documents internes d’EDSC, qui ne sont malheureusement accessibles que sur le réseau ministériel d’EDSC.

Table des matières

• Introduction
  • Objet
  • Public cible
  • Analyse de rentabilisation (contexte stratégique)
• Politique d’orientation
  • Gouvernance, conformité et rapports
  • Planification des capacités
  • Architecture
  • Gestion de produits
  • DevOps
• Ensemble cohérent de mesures
• Mesurer la réussite de la stratégie
• Approche de mise en œuvre (en plusieurs étapes)
• Annexe A – Diagnostic (difficultés qui nous empêchent d’aller de l’avant)
• Annexe B – Matrice de traçabilité
• Annexe C – Références
• Annexe D – Définitions
• Annexe E – Liste des acronymes et définitions
• Annexe F – Statistiques concernant les grands projets axés sur la TI

Introduction

Objet

Fournir à EDSC un cheminement vers la livraison des logiciels le jour même.

Cette stratégie comprend :

1. un diagnostic, dans le cadre d’une analyse de rentabilisation de la stratégie définissant les problèmes qui nous empêchent d’avancer;
2. une politique d’orientation, qui sert à communiquer une décision du DPI et à décrire l’état cible;
3. un ensemble cohérent de mesures (un plan d’action), qui sert à opérationnaliser la politique d’orientation.

Cette stratégie vise à communiquer une décision du DPI (qui n’a pas encore été approuvée) sur la voie à suivre (la politique d’orientation) et les investissements nécessaires pour opérationnaliser cette décision (l’ensemble cohérent de mesures).

Public cible

Le présent document stratégique s’adresse aux intervenants qui participent à la détermination de la façon dont les solutions de TI seront livrées. Plus précisément, elle s’adresse aux intervenants qui participent à la définition des règles d’acquisition (que ce soit par voie de conception, d’achat, d’adoption ou de configuration), la prestation, l’opérationnalisation et la maintenance des solutions de TI (voir l’Annexe D pour connaître la signification des termes). Cela comprend les intervenants de la DGIIT et ceux qui ne font pas partie de la DGIIT, comme la DGDPF, la DGAIGRE, le BDPD et SPC. Vous dans l’ensemble cohérent des mesures une liste des intervenants qui devraient participer à la mise en œuvre de cette stratégie.

Une fois mise en œuvre, la politique d’orientation ciblera les intervenants concernés lorsque des projets axés sur les TI seront conceptualisés et créés, que des solutions de TI seront conçues et que des produits de TI seront élaborés, livrés, mis en œuvre et mis à niveau. Tous les membres du personnel d’EDSC qui prennent part aux décisions d’investissement en TI devront respecter la présente politique d’orientation.

Analyse de rentabilisation (contexte stratégique)

Le passage à l’ère numérique met en évidence l’omniprésence de la technologie dans la prestation des services aux Canadiens. Par conséquent, pour itérer ses politiques et ses offres de services¹, EDSC devra apporter des changements à ses technologies. Afin d’assurer une meilleure prestation de services aux Canadiens, nous devons améliorer la réactivité de la TI, sinon la boucle de rétroaction entre les décideurs et les Canadiens sera trop longue, ce qui aura des répercussions sur la capacité d’EDSC d’itérer sa capacité d’élaboration de politiques et de devenir une organisation agile.

Figure 1. À l’ère numérique, la technologie permet de relier les décideurs et les Canadiens

EDSC a besoin de déploiements de production pour obtenir les données empiriques nécessaires à la prise de décisions fondées sur des données probantes.

EDSC n’est pas un nouveau ministère. Il a accumulé une dette technique importante² au cours de ses décennies d’activités, ce qui a une incidence sur la réactivité des TI. Le portefeuille d’applications d’EDSC contient plus de 500 applications (anglais seulement)³, dont 101 sont essentielles à la mission et reposent sur des technologies existantes (applications personnalisées et ordinateurs centraux désuets). En réponse aux limites des systèmes de TI désuets, EDSC a commencé à investir dans un programme de modernisation de la prestation des activités⁴.

Toutefois, le recours aux TI est un investissement risqué et coûteux⁵.

La plupart des recommandations issues des audits externes⁶ sur la réduction des risques liés aux investissements dans la technologie semblent viser une gouvernance plus solide et plus disciplinée. Il est essentiel de pouvoir prévoir plus précisément ce que nous réserve l’avenir, afin de réduire les risques liés à ce type d’investissements.

Toutefois, pour travailler efficacement dans le monde numérique, il faut d’abord accepter la complexité et l’incertitude, ce qui exige une approche très différente pour mener à bien toute initiative. Un monde prévisible récompense la planification précoce et l’exécution rigide des plans. À l’inverse, un monde complexe et incertain récompense un cycle empirique d’essai, d’observation et de correction.⁷

Les méthodes actuelles de gestion des investissements en TI visent deux grands objectifs⁸ :

1. Gestion des risques liés aux investissements en TI
2. Cibler les investissements là où il y a des avantages

Cette stratégie vise à améliorer les deux objectifs susmentionnés en proposant de faire en sorte qu’EDSC soit en mesure de déployer ses logiciels le jour même et que cela devienne une pratique courante. Les avantages de petits déploiements fréquents au moyen de méthodes automatisées devraient permettre de réduire les risques⁹, d’atténuer la dette technique, d’accroître la satisfaction des clients et de rehausser la confiance globale envers le ministère et son personnel. Cela est maintenant possible grâce à l’adoption de technologies infonuagiques et de pratiques DevOps.

Le passage au numérique permet de mettre davantage l’accent sur les données comme étant l’actif dont l’organisation se soucie. C’est grâce aux données que l’organisation recueillera de l’information et éclairera ses décisions en matière d’amélioration des services¹⁰. Pour pouvoir apporter rapidement des changements sur le plan des logiciels, il faudra traiter les données comme un concept distinct, non pas dépendant des logiciels, mais plutôt interrelié à ceux-ci. Consultez l’annexe D (Définitions) pour connaître les liens qui existent entre une solution de TI, une application, un logiciel et des données.

Bref, cette stratégie vise à modifier les conditions organisationnelles de sorte qu’EDSC puisse réussir sa transformation numérique¹¹.

Cette stratégie misera sur les initiatives de TI existantes (comme La voie à suivre pour la DGIIT (anglais seulement), l’étude indépendante de PwC, le cadre des opérations infonuagiques et le programme de redressement de la dette technique), en les mettant à l’avant-plan et en y intégrant de nouvelles activités.

L’objectif de cette stratégie est de définir ce qu’est l’état cible de la prestation des solutions de TI et de présenter une feuille de route pour atteindre cet état cible.

L’annexe A – Analyse de rentabilisation (diagnostic) explique les difficultés qui nous empêchent d’effectuer le déploiement des logiciels le jour même.

Politique d’orientation

La politique suivante reflète la décision adoptée par le DPI d’EDSC (le DPI n’a pas encore donné son approbation) dans le cadre de l’utilisation du modèle de prestation de la solution de TI cible. Chaque énoncé stratégique représente une déclaration de cette décision et a reçu l’aval des secteurs de gouvernance concernés (les approbations n’ont pas encore été obtenues, voir l’ensemble cohérent de mesures).

Cette politique d’orientation s’appliquera lorsque des solutions de TI devront être mises en œuvre. Une fois qu’elle sera en vigueur, toutes les équipes participant au projet, ainsi que les produits de TI faisant partie de la solution de TI, devront s’y conformer.

La présente politique d’orientation a été préparée en tenant compte de l’harmonisation et de la conformité aux instruments de politique existants et ne vise pas à les remplacer. Les intervenants doivent continuer de se conformer aux instruments de politique existants, notamment :

• Politique sur la gestion des projets et des programmes (PGPP) (anglais seulement) d’EDSC
• Directive sur la gestion des programmes (anglais seulement) d’EDSC
• Directive sur la gestion des projets (anglais seulement) d’EDSC
• Politiques d’approvisionnement (anglais seulement) d’EDSC
• Stratégie de données (anglais seulement) d’EDSC
• Directive sur les services et le numérique du CT
• Directive sur la gestion de la sécurité du CT
• Directive sur la prise de décisions automatisée du CT

Gouvernance, conformité et rapports

1. Les équipes DevOps ont le pouvoir d’effectuer des changements au moyen de pipelines DevOps fiables.
2. La définition d’une équipe DevOps correspond à la <définition normalisée de la DGIIT>.
3. Les pipelines DevOps satisfont aux <critères minimaux normalisés en matière de gestion du changement> en vue de promouvoir la mise en production et l’intégration des logiciels.
4. Les équipes DevOps publient leurs mesures de développement à l’interne à EDSC, tel que défini dans les <mesures de développement normalisées pour les équipes DevOps>.
5. Les produits de TI publient leurs paramètres de production à tout le moins à l’interne à EDSC, tel que défini dans les <mesures de production normalisées pour les produits de TI>.
6. Les évaluations et les autorisations de sécurité (EAS) s’appuient sur la <méthodologie de l’état cible et de l’EAS>.
7. L’évaluation de l’accessibilité s’appuie sur la <méthodologie d’évaluation de l’état cible et de l’accessibilité>.
8. L’évaluation de l’audit financier s’appuie sur la <méthodologie d’évaluation de l’état cible et des finances>.
9. L’évaluation automatisée des systèmes de prise de décisions automatisée s’appuie sur la <méthodologie d’évaluation de l’état cible et des SDA>.
10. Les projets axés sur la TI produisent des produits de TI prêts à la production au moins tous les six mois
11. Les projets axés sur la TI commencent lorsque les conditions minimales de réception des projets axés sur la TI sont remplies, tel que défini dans la <norme sur les conditions de réception des projets axés sur la TI>.
12. Les projets axés sur les TI s’appuient sur le <cadre de gouvernance agile des projets axés sur la TI>.

Planification des capacités

1. La planification des capacités exploite les équipes DevOps comme des unités (et non comme des personnes).
2. Les projets axés sur la TI sont affectés à une combinaison d’équipes DevOps prédéfinies.

Architecture

1. Les solutions de TI sont couplées librement aux capacités opérationnelles, tel que défini dans la <stratégie d’adoption, de conception et d’achat>.
2. Les applications, qui composent les solutions de TI, sont couplées librement aux données de l’organisation.
3. Les composants logiciels, qui composent les applications, sont couplés librement entre eux.
4. Les responsables des produits de TI peuvent effectuer des essais, déployer et apporter des changements techniques indépendamment des autres équipes de DevOps associées au produit de TI.
5. Les équipes DevOps ont le pouvoir de choisir les combinaisons de technologies pour leurs produits de TI, à moins que ces combinaisons comprennent des technologies devant être confinées ou retirées, tel que défini dans la <Gestion des normes technologiques>
6. Les produits de TI exposent leurs fonctionnalités et leurs données au moyen d’IPAs sécurisées.
7. La portée des projets axés sur les TI qui ont une incidence sur les applications existantes est déterminée en fonction du <modèle de conception en goulot d’étranglement>, conformément à la <_vision de l’architecture cible pour les applications existantes>.
8. Les applications existantes sont des systèmes énumérés dans la <liste normalisée des applications existantes d’EDSC>.

Gestion de produits

1. Les solutions de TI et les applications sont gérées comme des produits (appelés produits de TI).
2. Les produits de TI n’ont qu’un seul responsable de produit; celui-ci dispose des pouvoirs nécessaires pour approuver les changements qui seront apportés.
3. Les produits de TI sont soutenus par une ou plusieurs équipes DevOps.
4. Les projets axés sur la TI comblent les arriérés des produits de TI visés par le projet.
5. Les équipes DevOps soutiennent leurs produits de TI qui sont en production et sont responsables de gérer le temps de disponibilité de ces produits.
6. Les arriérés des produits de TI sont catégorisés comme étant non discrétionnaires ou discrétionnaires.

DevOps

1. Les équipes DevOps utilisent un pipeline pour contrôler le processus de lancement, de l’étape de l’engagement à celle de la production.
2. Le pipeline DevOps permet une intervention manuelle si nécessaire.
3. Les équipes DevOps comptent un maximum de neuf membres multidisciplinaires.
4. Les équipes DevOps ont recours à l’automatisation des outils d’immotique.
5. Les équipes DevOps ont recours à l’automatisation des essais pour :
   • Essais unitaires
   • Essais d’intégration
   • Automatisation des essais de sécurité
   • Essais d’accessibilité
   • Essais de rendement
   • Essais fonctionnels
   • Test de fumée
6. Les équipes DevOps ont recours à l’intégration continue.
7. Les équipes DevOps ont recours à l’automatisation du lancement des applications.
8. Les équipes DevOps ont recours à un système de contrôle des versions axé sur Git.
9. Les équipes DevOps ont recours à la surveillance automatisée.

Ensemble cohérent de mesures

Les mesures suivantes doivent être prises pour que le modèle de prestation de la solution de TI cible soit opérationnel.

Mesurer la réussite de la stratégie

Le succès de cette stratégie sera mesuré en comparant les mesures suivantes à la méthodologie conventionnelle propre aux projets de TI.

Les mesures sont définies comme suit :

1. Délai d’exécution des changements: temps nécessaire pour modifier le code, de l’étape de la vérification à celle de la mise en production
2. Fréquence de déploiement : fréquence à laquelle le logiciel est déployé dans l’environnement de production ou diffusé aux utilisateurs finaux
3. Échec des changements: taux d’échec des changements, mesuré selon la fréquence des échecs de déploiement dans l’environnement de production, nécessitant une correction immédiate
4. Délai de reprise: temps qui s’écoule entre la détection d’un incident ayant une incidence sur les utilisateurs et la prise de correctifs
5. Satisfaction des clients: niveau général de satisfaction des clients à l’égard des applications faisant partie du portefeuille de la GPA et des produits de TI

Manuelle: la collecte de données nécessite une intervention manuelle (p. ex., tenue de sondages au moyen du logiciel SimpleSurvey, entrevues, courriels, mises à jour de chiffriers).

Automatique: la collecte de données est effectuée automatiquement, habituellement par des moyens programmatiques (p. ex., événements déclenchés dans un répertoire Git quand un nouvel engagement est pris et mises à jour de la « vue » globale du tableau de bord).

REMARQUE : les quatre premières mesures (a, b, c et d) sont les 4 indicateurs clés définis par le DevOps Research Assessment Institute (DORA) (anglais seulement).

Approche de mise en œuvre (en plusieurs étapes)

Il est entendu que l’ambition de la stratégie ne se concrétisera pas d’un seul coup ou dans quelques années. L’approche de mise en œuvre se fera de manière itérative, en vue d’atteindre l’état cible en trois étapes :

1. Étape 1 : Fondements et sensibilisation
   • Exposer les équipes de TI d’EDSC existantes qui ont déjà atteint ou presque l’état cible en favorisant leur visibilité au sein de l’organisation et en leur accordant le pouvoir de poursuivre leurs activités dans l’état cible (p. ex., équipes du projet de RPC-E).
   • Sanction 1 - Produit de TI fonctionnant selon le nouveau modèle d’état cible
   • Sanction 1 - Projet axé sur la TI fonctionnant selon le nouveau modèle d’état cible
   • Créer temporairement (sur une durée de trois ans) une communauté d’excellence DevOps financée, qui agira à titre d’agent de changement et d’encadrement pour les équipes de TI existantes d’EDSC en vue de l’adoption des processus DevOps.
   • Désigner des « champions » par fonctions. Ces champions offriront des services d’encadrement et de mentorat à d’autres équipes (c.‑à‑d. que ce sera le début des « équipes habilitantes » auxquelles fait référence le concept de topologie d’équipe (Team Topology)¹²).
   • Sensibiliser les parties intéressées au fait que les administrateurs de systèmes doivent adopter le rôle d’ingénieurs de la fiabilité des sites.
2. Étape 2 : État de préparation de l’infrastructure et des systèmes existants
   • Cerner deux projets axés sur la TI touchant des systèmes existants aux fins de mise à l’essai et les orienter en vue de leur permettre d’atteindre l’état cible (conformément à la vision de l’architecture cible pour les systèmes existants).
   • Fournir des pipelines DevOps communs que les équipes de TI pourront utiliser (financés, ayant passé le processus d’EAS et ayant été adoptés comme normes techniques).
   • Expérimenter avec des environnements hors production, pour les systèmes existants, dans le nuage public (p. ex., environnements d’essai).
3. Étape 3 : Portée
   • Désigner des « équipes de plateforme » pour fournir des services aux équipes DevOps, au moyen d’outils et d’IPA.
   • Désigner des « équipes des sous-systèmes complexes » pour fournir une expertise spécialisée aux équipes DevOps (p. ex., ordinateurs centraux, mathématiques complexes, analytiques).
   • Produire la structure organisationnelle de la DGIIT (axée sur les équipes multifonctionnelles) et son modèle financier connexe.
4. Étape 4 : Normalisation et gestion des systèmes existants
   • Obliger tous les nouveaux projets axés sur la TI (qui ne touchent pas aux infrastructures existantes) à se conformer au modèle d’état cible.
   • Obliger tous les projets axés sur la TI existants (qui touchent aux infrastructures existantes) à se réorienter pour atteindre le modèle d’état cible (conformément à la vision de l’architecture cible pour les systèmes existants).

Annexe A – Diagnostic (difficultés qui nous empêchent d’aller de l’avant)

En vertu de la Politique sur les services et le numérique, qui reflète les attentes des citoyens, EDSC est tenu d’examiner périodiquement les services fournis aux clients. Étant donné la nature omniprésente de la technologie, tout changement aux services d’EDSC nécessitera la participation des équipes de TI.

La Directive sur les services et le numérique précise comment les DPI (et les DPD) ministériels ont leur mot à dire sur la façon dont les ministères procèdent à leur transformation numérique.

Les méthodes actuelles de gestion des investissements en TI sont guidées par l’instrument de politique financière d’EDSC suivant : Politique sur la gestion des projets et des programmes (PGPP) (anglais seulement). Il s’agit de la politique qui a donné lieu à la Norme sur la gestion de projet (anglais seulement), laquelle énonce les principales exigences pour le personnel d’EDSC qui travaille dans un environnement de projet. La norme actuelle vise à gérer les risques et les coûts grâce à une planification avancée et à une exécution rigoureuse du plan. L’approche par points de contrôle de la gestion de projet exige que les équipes de projet demandent l’autorisation avant de continuer. Cette autorisation est accordée lorsqu’une preuve suffisante de diligence raisonnable et un portrait fidèle de l’avenir sont fournis. Cela peut se faire lorsque l’avenir est prévisible, mais pas quand les étapes à venir sont complexes et incertaines. Son incidence négative favorise l’introduction de nouvelles caractéristiques, car le fardeau du processus de demande d’autorisation pour aller de l’avant fait en sorte qu’il est dissuasif de déployer de petits changements.

Le passage à ce monde hautement intégré, complexe et incertain qu’est le monde numérique nous oblige à opter pour un cycle d’essai, d’observation et de correction de trajectoire plus empirique. Le lien entre les phases de planification et d’exécution devient cyclique. C’est grâce à l’exécution que nous obtenons les données empiriques nécessaires pour éclairer nos estimations de planification et décider des correctifs à apporter. Les pratiques récentes en matière de développement de logiciels, principalement dans les domaines de l’infonuagique et de DevOps, nous ont permis d’adopter cette approche. Les équipes de TI n’ont plus besoin d’attendre pendant de longues périodes pour obtenir des serveurs, élaborer d’importantes bases de code et chercher de grands investissements en capital à des fins d’infrastructure. L’infonuagique a commercialisé l’infrastructure de TI, ce qui permet à EDSC de développer, de mettre à l’essai et de déployer rapidement des logiciels.

De plus, le GC s’éloigne des solutions monolithiques (anglais seulement) (vaste base de codes regroupant de nombreuses capacités, mais qui cause des goulots d’étranglement et des points de défaillance uniques dans l’écosystème des TI lorsque les nombreuses équipes de TI qui participent aux travaux entrent en collision)¹⁴.

La Directive sur la gestion de projets et programmes du CT laisse place à l’approche ci-dessus :

• [Le promoteur de projet est responsable de :] 4.2.5 Maintenir des relations efficaces avec les intervenants externes clés, notamment avec les ministères concernés et les fournisseurs de services communs.
• [Le promoteur de projet est responsable de :] 4.2.8 Appliquer, selon le cas, des méthodes et des principes incrémentiels, itératifs, souples et axés sur les utilisateurs pour la planification, la définition et la mise en œuvre du projet.
• [Le promoteur de projet est responsable de :] 4.2.18 Mettre en place, dès le début du projet, un plan des points de contrôle du projet conforme au cadre ministériel qui : [4.2.18.1] documente les décisions qui seront prises à chaque point de contrôle, les éléments probants et les renseignements requis à l’appui des décisions aux points de contrôle, les critères utilisés pour évaluer les éléments probants et la gouvernance des points de contrôle.

Les trois exigences susmentionnées issues de la Directive du CT indiquent que les ministères doivent accepter le changement et s’y adapter, ainsi que prendre des décisions fondées sur des données probantes (comme les décisions de planification). De telles données probantes ne peuvent être obtenues que par l’exécution.

La DGIIT a déployé des efforts pour moderniser sa gestion des technologies, comme en témoignent le Coin des félicitations dans le Bulletin de nouvelles de la DGIIT (anglais seulement)¹⁵ et le plan La voie à suivre pour la DGIIT (anglais seulement)¹⁶. Toutefois, la relation d’EDSC avec la technologie dépasse l’influence de la DGIIT.

Pour faire d’EDSC une organisation agile, il faut adopter un modèle qui permettra de déployer des logiciels plus petits et de manière plus fréquente, car ce sont ces déploiements qui permettront à l’organisation de recueillir les données empiriques nécessaires pour prendre des décisions fondées sur des données probantes.

Annexe B – Matrice de traçabilité

La matrice de traçabilité suivante est utilisée pour démontrer l’harmonisation avec divers plans, stratégies et instruments de politique déjà en cours.

Annexe C – Références

• Politique sur la gestion des projets et des programmes (PGPP) (anglais seulement) d’EDSC
• Directive sur la gestion des projets (anglais seulement) d’EDSC
• Directive de gestion des avantages (anglais seulement) d’EDSC
• Cycle de vie de la gestion de projet (anglais seulement) d’EDSC
• Stratégie de données (anglais seulement) d’EDSC
• Structure de gouvernance (anglais seulement) de la DGIIT
• Processus d’EAS relatif à la sécurité des TI
• Processus du CVDL (anglais seulement) (solution de rechange actuelle et proposée par les conseillers principaux et le BGPDG)
• Composition de l’équipe à l’étude (anglais seulement) par les conseillers principaux
• Politiques d’approvisionnement d’EDSC
• Directive sur les services et le numérique du cT
• Directive sur la gestion de la sécurité du cT
• Directive sur la gestion de projets et programmes du CT
• Directive sur la prise de décisions automatisée du CT
• SAFe (Scaled Agile Framework) (anglais seulement)
• Disciplined Agile (DA) (anglais seulement)
• Large-Scale Scrum (anglais seulement)
• Good Strategy, Bad Strategy (livre, anglais seulement)
• How to write rules that people want to follow (anglais seulement)

Annexe D – Définitions

Équipe DevOps (anglais seulement)

Une équipe interfonctionnelle et multidisciplinaire qui met l’accent sur la collaboration et la communication des développeurs de logiciels et des professionnels des technologies de l’information (TI), tout en automatisant le processus de déploiement des logiciels et de modification de l’infrastructure. Une équipe DevOps correspond à la définition normalisée suivante de la DGIIT (anglais seulement).

Une copie de la version Office 365 est disponible ici (anglais seulement).

Système de contrôle des versions décentralisé (DVCS)

Les systèmes de contrôle des versions centralisés reposent sur l’idée qu’il n’y a qu’une seule copie « centrale » d’un projet de logiciel quelque part (probablement hébergée sur un serveur) et que les développeurs modifient le code directement sur cette copie centrale.

Un système de contrôle de version décentralisé (DVCS) ne repose pas nécessairement sur un serveur central pour stocker toutes les versions des fichiers d’un projet de logiciel. Chaque développeur « clone » plutôt une copie d’un répertoire et stocke l’historique complet du projet sur son propre disque dur. Cette copie (ou « clone ») renferme toutes les métadonnées de l’original. Dans un DVCS, les développeurs apporteront habituellement des changements au code sur leur copie locale, mettront à l’essai ces changements au moyen de cette copie et les « transmettront » sur un serveur central hébergeant la copie « maîtresse » que le projet de logiciel est censé utiliser.

Les trois DVCS les plus populaires sont Mercurial, Git, et Bazaar.

EDSC utilisera Git pour favoriser l’interopérabilité entre les répertoires de codes sources et acceptera le fait que le marché a évolué et préconise maintenant les répertoires de codes sources axés sur Git.

Chaîne de valeur de développement

La série d’étapes et de développeurs qu’EDSC utilise pour mettre en œuvre des solutions de TI permettant à l’organisation de mener ses activités opérationnelles. Les personnes qui composent la chaîne de valeur du développement sont un ensemble d’équipes DevOps.

L’organisation des portefeuilles axée sur les chaînes de valeur de développement permet de visualiser le flux du travail pour produire des solutions, réduire les transferts et les retards, accélérer l’apprentissage et raccourcir la période de mise en marché, et soutenir des méthodes de développement et de budgétisation plus simples.

Solution de TI, application, logiciel et données

Une définition normalisée devrait être élaborée par le CEAI (voir l’ensemble cohérent de mesures de la stratégie d’adoption, de conception et d’achat_). Jusqu’à ce que cela soit terminé, la définition et les liens suivants seront utilisés.

Figure 2. Modèle de relations entre les différents éléments logiciels

La solution de TI est composée d’une ou de plusieurs applications. Il s’agit essentiellement d’un regroupement d’applications.

Une application s’inscrit dans le cadre du Programme de gestion des portefeuilles d’applications (GPA) (anglais seulement)) et est constituée d’un ou de plusieurs logiciels (communément appelés composants logiciels). De plus, une application utilise ou produit des données en faisant office d’interface avec ses composants logiciels. Dans une application, les logiciels et les données sont des concepts distincts.

Un composant logiciel est une base de codes unique, un regroupement de fichiers (binaires ou texte qui sera compilé en binaire) qui seront exécutés dans une infrastructure. Un composant logiciel peut avoir des dépendances avec d’autres composants logiciels. C’est souvent le cas de ses bibliothèques – d’autres composants logiciels – qui sont conçues par d’autres équipes, adoptées à partir de licences de logiciels de source ouverte ou achetées auprès d’un fournisseur tiers. On s’attend à ce que le logiciel ait au moins un paramètre de configuration (p. ex., un fichier) propre à l’environnement dans lequel il est déployé.

L’infrastructure est l’endroit où le logiciel est déployé. Habituellement, il s’agit d’un serveur exécutant un système d’exploitation. Dans le nuage public, il peut s’agir de conteneurs ou d’autres plateformes en tant que service. Comme les logiciels, les infrastructures utilisent également les paramètres de configuration.

Les données avec lesquelles une application interagit font partie intégrante de la gestion des données de référence. Il s’agit de la source de renseignements d’une entité de données particulière; la confidentialité, l’intégrité et la disponibilité des données sont définies pour un contexte opérationnel donné, et le consentement de l’utilisateur final est communiqué à l’application.

Produit de TI

Un produit de TI se compose d’une solution de TI ou d’une application. La décision d’établir la portée d’un produit à l’égard d’une solution de TI ou d’une application dépend du contexte opérationnel particulier de l’organisation.

Dans le contexte de la gestion des produits, l’idée est que les solutions de TI ou les applications sont conçues pour croître et évoluer au fil du temps, contrairement aux projets qui ont un seul début, un milieu et une fin. Cela démontre que les solutions de TI et les applications utiliseront différentes méthodes de gestion des investissements pour s’améliorer continuellement.

Le « produit de TI » représente la partie technique d’un « produit » plus grand – l’ensemble des services offerts aux clients¹⁷(https://sara-sabr.github.io/ITStrategy/strategy-target-solution-delivery-model.html#fn:18).

Projet axé sur la TI

Il s’agit d’un effort provisoire déployé pour créer un produit, un service ou un résultat unique. La nature temporaire des projets axés sur la TI fait en sorte que ceux-ci ont un début et une fin bien définis.

Cette définition est tirée de la Directive sur la gestion des projets d’EDSC (anglais seulement) et a été modifiée afin de tenir compte de l’aspect des TI.

Responsable de produit de TI

Personne qui représente l’organisation ou la communauté d’utilisateurs et qui est chargée de travailler avec ces personnes pour déterminer les fonctionnalités qui seront incluses dans la version du produit.

Équipes des produits TI

Comprends un ensemble d’équipes DevOps nécessaires à l’exploitation et à la maintenance de la suite de logiciels dont le produit de TI est composé. Les gestionnaires et les organisateurs (p. ex., architecte en chef) font également partie d’une équipe de produit de TI.

Modèle conventionnel de prestation des solutions de TI

Aux fins de la présente stratégie, nous définissons le modèle conventionnel de prestation des solutions de TI comme étant le statu quo actuel.

Le modèle conventionnel suit le processus par points de contrôle du CVGP et favorise la planification avancée et l’exécution rigoureuse d’un plan fondé sur la portée, l’échéancier et les coûts engagés, et rendra compte de ces engagements afin de déterminer l’état de santé des projets de TI.

Dans le modèle conventionnel, les équipes de TI sont organisées par fonction et des transferts de charge de travail leur sont affectés tout au long de la chaîne de développement pour leur permettre d’accomplir leurs tâches fonctionnelles. Ces transferts sont définis en tenant compte des fonctions de l’équipe et non du résultat global du projet.

Dans le modèle conventionnel, on s’attend à ce que les résultats opérationnels soient atteints à la fin du projet de TI et que les activités opérationnelles soient modifiées en fonction des nouvelles capacités établies par le projet de TI. En vertu du plan de réalisation des activités, le responsable opérationnel est tenu de surveiller et de signaler les écarts entre les avantages prévus et réels. Les écarts sont traités en fonction des exigences en matière de changement ou des nouveaux projets.

Modèle de prestation de la solution de TI cible

Le modèle de prestation de la solution de TI cible a le même objectif que le modèle conventionnel : optimiser les ressources et réduire les risques grâce à l’utilisation de la technologie. Contrairement au modèle conventionnel, ce modèle visera à :

• limiter la taille des projets de TI;
• définir les projets de TI dans leur intégralité, de l’étape de l’itération jusqu’à l’établissement des objectifs opérationnels de l’organisation;
• exiger des engagements des commanditaires opérationnels tout au long de l’exécution des projets de TI;
• favoriser la mentalité DevOps en vue d’améliorer le flux d’information et d’accélérer la prestation (c.‑à‑d. en ayant recours à des équipes de prestation plutôt qu’à une série d’équipes fonctionnelles réparties);
• mesurer la valeur opérationnelle obtenue au fil du temps au lieu d’utiliser des estimations strictes des échéanciers, des coûts et de la portée.

Annexe E – Liste des acronymes et définitions

Annexe F – Statistiques concernant les grands projets axés sur la TI

Voici des statistiques et des références concernant les problèmes et les taux de réussite des grands projets axés sur la TI.

1) Étude du Standish Group

Le Standish Group, un organisme consultatif de recherche qui se concentre sur le rendement du développement de logiciels¹⁸, a constaté que « de 2003 à 2012, parmi les 3 555 projets recensés dont le coût de main-d’œuvre s’élevait à au moins 10 millions de dollars, seulement 6,4 % ont été fructueux. Les données du Standish Group ont montré que 52 % des grands projets étaient « remis en question », soit parce qu’ils dépassaient le budget, qu’ils étaient en retard ou qu’ils ne répondaient pas aux attentes des utilisateurs. Les 41,4 % restants étaient des échecs — c.‑à‑d. que ces projets ont été soit abandonnés, soit recréés à partir de zéro. »¹⁹

L’étude et les résultats du Standish Group ont également été cités dans le chapitre 3 du rapport de novembre 2006 de la vérificatrice générale du Canada (énoncés 3.5 et 3.6). Voir le point 3 ci-dessous.

2) Questions à la Chambre des communes de 2016 et 2019 (projets de plus de 1 M$)

Grâce à un projet d’Ottawa Civic Tech, un ensemble de données sur les grands projets de TI du gouvernement (anglais seulement)²⁰ a été publié et les réponses à deux questions qui ont été posées à la Chambre des communes, en juin 2016 et en mai 2019, ont été consignées. Chaque question demandait aux ministères fédéraux de faire rapport sur les projets de TI, en cours ou prévus, d’une valeur supérieure à 1 M$.

Nous avons fait les constatations suivantes :

• Des 94 projets qui contiennent suffisamment de données pour comparer les échéanciers : 9 % respectent les échéanciers, 4 % sont en avance et 87 % sont en retard.
• Des 97 projets qui contiennent suffisamment de données pour comparer les budgets : 26 % se situent à 10 % ou moins des estimations initiales, 28 % se situent entre 10 % et 50 % au-dessus des estimations initiales, 28 % se situent à plus de 50 % des estimations initiales et 19 % se situent à moins de 10 % des estimations initiales.

3) Chapitre 3 du rapport de novembre 2006 de la vérificatrice générale du Canada²¹

La vérification portait sur sept projets et les évaluait selon quatre critères clés (gouvernance, analyse de rentabilisation, capacité organisationnelle et gestion de projet).

Dans les énoncés 3.5 et 3.6, le rapport fait mention de l’étude du Standish Group (voir le point 1) ci-dessus) en ce qui a trait au faible taux de réussite des grands projets de TI. Il fait également référence à un rapport de 2000 selon lequel une tendance se dessinait dans les projets de TI : « pour la plupart des nouveaux projets on suivait sa recette du succès, c’est-à-dire limiter leur durée à six mois et le nombre d’intervenants à six. »

Le rapport concluait que, dans l’ensemble, le gouvernement avait fait peu de progrès depuis la dernière vérification (1997), n’avait pas expliqué de façon adéquate les résultats attendus dans le cadre d’une analyse de rentabilisation et n’avait pas évalué de façon adéquate sa capacité de prendre en charge des projets de TI à risque élevé. Toutefois, le rapport conclut que 4/7 des projets échantillonnés étaient bien gérés.

4) Rapport du printemps 2010 de la vérificatrice générale du Canada²²

Le rapport visait à déterminer si cinq des entités gouvernementales ayant les plus importantes dépenses en matière de TI avaient cerné et géré de façon adéquate les risques liés aux systèmes de TI vieillissants. Toutes les entités indiquaient que le vieillissement de la TI représentait un risque important et la majorité d’entre elles (dont EDSC) l’avaient inclus dans leur profil de risque organisationnel.

Le rapport stipulait que les plans d’investissement n’étaient pas appuyés par une stratégie de financement dans le cadre de laquelle des sources de fonds suffisantes étaient fournies pour mener à bien toutes les initiatives nécessaires à la gestion de la TI vieillissante. En 2008, RHDCC a préparé un plan d’investissement à long terme comprenant 20 projets et initiatives dont le coût s’élevait à 947,4 millions de dollars sur 5 ans. Le plan n’a pas été approuvé par la haute direction.

Le rapport indiquait que la Direction du dirigeant principal de l’information (DDPI) du SCT était au fait des risques importants liés au vieillissement de la TI depuis plus d’une décennie. La DDPI a répondu au rapport en affirmant qu’elle souscrivait aux recommandations, mais que la responsabilité des initiatives de financement relevait des administrateurs généraux des ministères et non de la DDPI.

5) 2011 juin — Rapport Le Point de la vérificatrice générale du Canada, chapitre 2 (grands projets de TI)²³

Ce rapport portait sur les progrès accomplis depuis le rapport de 2006 portant sur sept grands projets de TI; un nouveau projet venait également d’être sélectionné et approuvé par le Conseil du Trésor.

La conclusion était les progrès accomplis par le gouvernement en réponse aux recommandations de 2006 étaient insatisfaisants.

6) Rapport 5 – Rapport du printemps 2015 du vérificateur général du Canada (investissements dans les TI de l’ASFC)²⁴

Ce rapport présentait les résultats d’une vérification du rendement, c’est-à-dire une évaluation indépendante, objective et systématique de la façon dont le gouvernement gère ses activités, ses responsabilités et ses ressources.

Dans l’ensemble, le rapport a révélé que l’ASFC « avait été confrontée à des difficultés importantes en ce qui a trait à la gestion de son portefeuille d’investissements dans les technologies de l’information (TI) de manière à pouvoir assurer la mise en œuvre de projets en TI qui respectent les exigences établies et produisent les avantages escomptés. »

7) Rapport 1 – Rapport du printemps 2018 du vérificateur général du Canada (création et déploiement du système de paye Phénix)²⁵

La vérification visait à déterminer si Services publics et Approvisionnement Canada (SPAC) gérait et supervisait de façon efficace et efficiente la mise en œuvre du nouveau système de paye Phénix.

Le rapport a conclu que « le projet Phénix a été un échec incompréhensible de gestion et de surveillance de projet. Les cadres responsables de Phénix ont donné la priorité à certains aspects, comme les limites du budget et le calendrier, au détriment d’autres aspects essentiels tels que la fonctionnalité et la sécurité. Les cadres responsables de Phénix n’ont pas saisi l’importance des mises en garde indiquant que le Centre des services de paye de Miramichi, les ministères et organismes et le nouveau système n’étaient pas prêts. Ils n’ont pas communiqué une information complète et exacte aux sous-ministres et aux sous-ministres délégués des ministères et organismes, y compris au sous-ministre de Services publics et Approvisionnement Canada, lorsqu’ils les ont informés de l’état de préparation de Phénix en vue de sa mise en œuvre. À notre avis, la décision des cadres responsables de Phénix de mettre en œuvre Phénix était déraisonnable, compte tenu de l’information qui était disponible à ce moment-là. Le système n’a donc pas répondu aux besoins des utilisateurs, a coûté au gouvernement fédéral des centaines de millions de dollars et a causé des difficultés financières à des dizaines de milliers de ses employés. »

8) Février 2020 – Présentation de 18F devant le Michigan Senate Appropriations Committee²⁶

En février 2020, 18F (l’équivalent aux États-Unis du Service numérique canadien) a fait une présentation au Michigan Senate Appropriations Committee. 18F a été créé en 2014 par le programme Presidential Innovation Fellows (PIF, mis sur pied en 2012 par la Maison-Blanche) afin d’améliorer et de moderniser les technologies du gouvernement[28]. La présentation portait sur l’approvisionnement technologique et les défis connexes. En bref, les ministères gouvernementaux ne sont pas en mesure d’encadrer adéquatement les problèmes en partie gérables et, par conséquent, s’engagent dans des contrats de longue durée, de grande envergure et complexes avec des fournisseurs.

9) Delivering large-scale IT projects on time, on budget, and on value, McKinsey Digital, 2012²⁷

Selon une étude réalisée en 2012 par McKinsey Digital en collaboration avec l’université d’Oxford, 45 % des grands projets de TI (plus de 15 millions de dollars) visés dépassent le budget prévu et 7 % dépassent les échéanciers fixés, et ces projets offrent 56 % moins de valeur que ce qui était prévu. Les projets logiciels présentent le risque le plus élevé de dépassement des coûts et des échéanciers. L’étude a aussi permis de constater que plus un projet doit durer longtemps, plus il est probable qu’il dépasse le budget et le temps impartis. On y recommande quatre façons d’améliorer le rendement des projets, y compris la constitution d’équipes efficaces et le recours à des cycles de prestation de courte durée.

Références en ligne