Directive sur la gestion des technologies de l'information

La technologie de l’information (TI) permet au gouvernement fédéral d’exécuter ses opérations et la transformation des services. La TI est essentielle, sur le plan stratégique, pour accroître la productivité et améliorer les services gouvernementaux au public pour le bienfait des citoyens, des entreprises, des contribuables et des employés.
Modification : 2018-12-03

Outils sous-jacents

Lignes directrices :

Norme :

Renseignements supplémentaires

Politique :

Terminologie :

Sujet :

Hiérarchie

Voir la hiérarchie complète

Archives

Cette directive remplace :

Voir tous les instruments inactifs
Version imprimable XML

1. Date d'entrée en vigueur

La présente directive entre en vigueur le 1 avril 2009 et incorpore les modifications en vigueur le 4 décembre 2018.

2. Application

2.1 La présente directive s'applique à tous les ministères aux termes de l'article 2 de la Loi sur la gestion des finances publiques (LGFP), sauf si des lois, des règlements ou des décrets en conseil les en excluent.

2.2 Les sections 6.2.2 et 7.1 de la présente directive ne s'appliquent pas au Bureau du vérificateur général, au Commissariat à la protection de la vie privée, au Commissariat à l'information, au Bureau du directeur général des élections, au Commissariat au lobbying, au Commissariat aux langues officielles et au Commissariat à l'intégrité du secteur public. Dans ces organisations, les administrateurs généraux sont seulement responsables de surveiller et d'assurer la conformité à la présente directive et d'intervenir dans les cas de non conformité, suivant tout instrument du Conseil du Trésor offrant des principes et des directives sur la gestion de la conformité.

3. Contexte

3.1 Les technologies de l'information (TI) permettent au gouvernement fédéral d'exécuter ses opérations et la transformation des services. Les TI sont essentielles, sur le plan stratégique, pour accroître la productivité et améliorer les services au public au profit des citoyens, des entreprises, des contribuables et des employés. La présente directive assure un appui essentiel à l'égard de la gestion des TI dans les secteurs de la gouvernance des TI, de la planification des TI et des stratégies en matière de TI.

3.2 Le gouvernement du Canada investit une portion importante de son budget annuel dans les TI et l'infrastructure connexe. L'évolution rapide de la technologie, les pratiques opérationnelles incompatibles et l'adoption d'une approche fragmentée à l'égard des investissements en matière de TI minent l'efficacité et l'efficience de la prestation des services et de l'exécution des programmes du gouvernement. La multitude de réseaux et de centres de données comporte également des risques considérables pour la sécurité. Il faut donc adopter une approche plus stratégique à l'égard des investissements en matière de TI afin d'assurer l'interopérabilité des systèmes ministériels et la compatibilité des pratiques opérationnelles.

3.3 La présente directive appuie la Politique sur la gestion des technologies de l'information en fournissant aux dirigeants principaux de l'information (DPI) des ministères ou l'équivalent, ou aux autres responsables qui appuient la gestion des TI, des exigences supplémentaires pour assurer l'uniformité dans les processus de gestion des TI.

3.4 La présente directive doit être lue à la lumière du Cadre stratégique pour l'information et la technologie , de la Politique sur la gestion des technologies de l'information et de la Politique sur la gestion de l'information . La Directive est également liée à la Politique de planification des investissements – Actifs et services acquis et à la Politique sur la gestion de projets . Le plan ministériel de TI est un élément du plan d'investissement plus vaste du ministère, qui vise une période de cinq ans (comme l'exige la Politique de planification des investissements – Actifs et services acquis ). Cependant, pour suivre le rythme des changements technologiques, le DPI du ministère ou l'équivalent examine le plan ministériel de TI une fois par an afin de le mettre à jour, au besoin, au moment de l'examen. Le plan ministériel de TI traite des volets stratégique, tactique et opérationnel de la gestion des TI.

3.5 Les autres exigences liées à la gouvernance des TI, à la planification des TI et aux stratégies en matière de TI seront définies dans les normes. La Direction du dirigeant principal de l'information (DDPI) du Secrétariat du Conseil du Trésor (SCT) publiera aussi des lignes directrices et des outils pour aider les ministères, au besoin.

3.6 Le Conseil du Trésor a délégué au secrétaire du Conseil du Trésor le pouvoir d'émettre la présente directive et d'y apporter des modifications administratives et techniques.

3.7 Le Secrétaire du Conseil du Trésor a subdélégué au Dirigeant principal de l'information du Canada le pouvoir d'émettre la présente directive et d'y apporter des modifications administratives et techniques.

4. Définitions

4.1 Les définitions à utiliser dans l'interprétation de la présente directive se trouvent à l'annexe A.

5. Énoncé de la directive

5.1 Objectifs

Les objectifs de la présente directive sont les suivants :

5.1.1 Assurer l'utilisation efficace et efficiente des technologies de l'information à l'appui des priorités gouvernementales et de l'exécution des programmes, d'une capacité d'innovation et de production accrues et de l'amélioration des services offerts au public;

5.1.2 Appuyer la gestion des TI à l'échelle du gouvernement en offrant des pratiques de gestion plus matures et éprouvées afin de réduire le chevauchement, de favoriser l'adoption d'autres modèles de services communs et partagés, de promouvoir l'harmonisation et l'interopérabilité, et d'optimiser la prestation des services.

5.2 Résultats attendus

Voici les résultats attendus de la présente directive :

5.2.1 Les intervenants assumeront leurs rôles et responsabilités à l'égard de la gestion des TI de manière plus efficace en participant à certains forums de gouvernance, de consultation et de groupes de travail.

5.2.2 L'efficience et l'efficacité dans la gestion des TI s'accroîtront au rythme de l'amélioration du processus décisionnel à tous les niveaux, assurant ainsi que les TI appuient l'exécution des programmes et optimisent l'utilisation des ressources.

5.2.3 L'utilisation par les ministères des biens et services communs ou partagés liés aux TI augmentera et garantira des gains d'efficacité.

5.2.4 Les TI permettront la mise en place de services plus novateurs et mieux adaptés.

5.2.5 L'uniformité des pratiques de sécurité s'accroîtra en fonction de la consolidation accrue des systèmes et des services.

6. Exigences

6.1 DPI du ministère ou l'équivalent

Le DPI ministériel ou l'équivalent est responsable de ce qui suit :

6.1.1 Gouvernance des TI

  • Établir des structures de gouvernance ministérielles, à l'appui d'un processus décisionnel efficace en matière de TI, qui seront approuvées par l'administrateur général
  • Coordonner, promouvoir et orienter les TI et collaborer avec le responsable opérationnel et d'autres intervenants à la transformation des activités axées sur les TI
  • Prendre part aux forums sur la gouvernance des TI du gouvernement fédéral, y compris aux forums du Conseil des dirigeants principaux de l'information (CDPI) , aux autres forums sur la gouvernance et aux forums consultatifs désignés portant sur les questions liées aux TI et à l'architecture des TI au sein du gouvernement fédéral
  • Trouver un équilibre entre les intérêts des ministères et ceux de l'ensemble du gouvernement et harmoniser les TI avec les stratégies et les orientations pangouvernementales
  • Conseiller le CDPI sur les décisions, les plans, les stratégies, les orientations, les progrès, les risques et les enjeux liés aux initiatives qui exercent un impact sur la prestation ou l'utilisation des services de TI dans tous les ministères
  • Surveiller et mesurer le rendement du ministère au chapitre de la gestion des TI à l'aide d'indicateurs de rendement clés ministériels et pangouvernementaux, s'il y a lieu
  • Conseiller l'administrateur général, en collaboration avec le responsable opérationnel et d'autres intervenants, sur l'incidence que pourraient avoir une loi ou des politiques nouvelles ou modifiées sur les plans ministériels de TI
  • Présenter au Comité d'examen de l'architecture intégrée du gouvernement du Canada des propositions liées à la conception, à l'élaboration, à l'installation et à la mise en œuvre de solutions ou de services numériques, de systèmes d'information, et d'applications (« initiatives numériques ») :
    • lorsque le ministère est disposé à investir au moins l'un des montants suivants afin de régler le problème ou de bénéficier de l'occasion :
      • 2,5 millions dollars pour les ministères qui n'ont pas de catégorie de la capacité organisationnelle de gestion de projets approuvée ou pour les ministères ayant une catégorie 1 de capacité organisationnelle de gestion de projets approuvée;
      • 5 millions de dollars pour les ministères ayant une capacité organisationnelle approuvée de gestion de projets de catégorie 2;
      • 10 millions de dollars pour les ministères ayant une capacité organisationnelle approuvée de gestion de projets de catégorie 3;
      • 15 millions de dollars pour le ministère de la Défense nationale;
      • 25 millions de dollars pour les ministères ayant une capacité organisationnelle approuvée de gestion de projets de catégorie 4;
    • qui font appel à des nouvelles technologies;
    • qui exigent une exception à toute directive ou norme applicable établie en vertu de la Politique sur la gestion de la technologie de l'information;
    • les propositions d'initiatives au niveau Protégé B ou inférieur à l'aide d'un modèle de déploiement autre que le nuage public pour l'hébergement d'applications (y compris l'infrastructure), le déploiement d'applications, ou le développement d'applications classées; ou,
    • selon les indications du dirigeant principal de l'information du Canada.
  • Veiller à ce que toutes les propositions présentées au Comité d'examen de l'architecture intégrée du gouvernement du Canada soient d'abord évaluées par le Comité d'examen de l'architecture ministérielle s'il est déjà en place.
  • Veiller à ce que les propositions au Comité d'examen de l'architecture intégrée du gouvernement du Canada soient présentées à la suite de l'examen des cas de concept pour les projets axés sur la TI conformément Procédures obligatoires entourant les analyses de concept pour les projets axés sur la TI, et avant l'élaboration d'une présentation au Conseil du Trésor ou d'une analyse ministérielle de rentabilisation.
  • Dans l'exercice des responsabilités en vertu de la section 6.2.10 de la Politique sur la gestion de la technologie de l'information, veiller à ce que toutes les initiatives ministérielles soient évaluées en fonction des exigences de l'annexe C : Procédures obligatoires pour l'évaluation de l'architecture intégrée et de l'annexe D : Procédures obligatoires pour les interfaces de programmation d'applications.

6.1.2 Planification des TI

  • Élaborer, mettre en œuvre ou soutenir un processus de planification ministérielle efficace des TI qui soit intégré au processus ministériel général de planification organisationnelle et qui suit le processus de planification des investissements pour appuyer les activités, favoriser la transformation et orienter les décisions en matière de TI
  • Concevoir un plan de TI et rédiger un rapport de progrès en matière de TI en fonction du plan établi à l'annexe B et le soumettre au SCT (DDPI), s'il y a lieu
  • Communiquer avec les intervenants ministériels et externes, et les mobiliser afin de veiller à ce que le plan de TI soit conforme pour appuyer les activités ministérielles et les orientations stratégiques pangouvernementales si elles sont appropriées

6.1.3 Stratégies en matière de TI

  • Élaborer et maintenir des pratiques et des processus ministériels efficients et efficaces en matière de gestion des TI en tenant compte de l' ITIL (Information Technologie Infrastructure Library) (en anglais) et du COBIT (Control Objectives for Information and related Technology) (en anglais) , eten accordant la priorité à la gestion des biens liés aux TI, au catalogue des services de TI et à l'établissement du prix et des coûts des services de TI, s'il y a lieu
  • Harmoniser les pratiques et les processus ministériels de gestion des TI, et l'architecture de la technologie, avec la stratégie, les orientations, les normes et les lignes directrices du gouvernement fédéral à mesure qu'elles deviennent disponibles et qu'elles évoluent sous la direction du CDPI
  • Prendre part, en tant que fournisseur de services ou d'utilisateur de services, aux activités de conception, de planification, d'évolution et de surveillance des services de TI communs ou partagés et aux solutions qui s'appliquent
  • Élaborer, mettre en œuvre et appuyer des stratégies ministérielles en vue de produire ou d'utiliser des services de TI communs ou partagés, ainsi que des solutions, en fonction des plans de TI
  • Harmoniser et documenter les services de TI, prévus ou actuellement offerts aux destinataires, conformément à la Politique sur la structure de la gestion, des ressources et des résultats . Le Profil des services de la technologie de l'information du GC offre une orientation supplémentaire pour l'harmonisation et la documentation des services de TI
  • Examiner et évaluer les services de TI sur une base périodique afin de cerner les possibilités d'accroître l'efficience, l'efficacité et la capacité d'innovation, telles que déterminées par la direction en collaboration avec les fournisseurs et les utilisateurs de services, et les autres intervenants

6.2 Surveillance et déclaration

6.2.1 Au sein des ministères

6.2.2 À l'échelle du gouvernement

  • Le SCT (DDPI) surveillera la conformité à la présente directive dans le cadre du processus d'évaluation fondé sur le CRG, des examens des présentations au Conseil du Trésor, des RMR, des évaluations et des études ministérielles qu'il a demandés.
  • Le SCT (DDPI) examinera la présente directive et son efficacité au terme d'une période de cinq ans après sa mise en œuvre. Lorsqu'une analyse des risques le justifiera, le SCT (DDPI) veillera également à ce que la présente directive fasse l'objet d'une évaluation.

7. Conséquences

7.1 L'inobservation pourrait avoir comme conséquence, entre autres, des suivis informels ou des demandes officieuses de la part du SCT, par exemple, une vérification externe et un rapport sur les mesures correctives.

8. Rôles et responsabilités des organisations gouvernementales

Nota : La présente section recense les autres ministères qui ont un rôle à assumer dans la gestion des TI. Elle ne confère en soi aucun pouvoir.

8.1 Le SCT (DDPI), en collaboration avec d'autres ministères, est responsable de ce qui suit :

8.1.1 Élaborer des instruments de politique, notamment des cadres, des politiques, des directives, des normes, des lignes directrices et des outils, et fournir des conseils et de l'orientation sur l'interprétation de ces instruments;

8.1.2 Établir les orientations stratégiques pangouvernementales en matière de TI, y compris dans les secteurs des TI qui offrent des avantages importants à l'échelle de l'administration fédérale ou qui permettent au gouvernement d'assumer le rôle directeur dans la réalisation de ces avantages;

8.1.3 Coordonner la mise en œuvre des orientations stratégiques pangouvernementales en matière de TI;

8.1.4 Communiquer avec le groupe des TI dans l'ensemble du gouvernement fédéral, et la mobiliser sur tout ce qui concerne les plans, les progrès, les risques et les enjeux liés à la gestion des TI au sein du gouvernement fédéral;

8.1.5 Concevoir des normes de compétence et d'autres normes professionnelles pour les spécialistes des TI du gouvernement fédéral, au besoin;

8.1.6 Offrir un soutien au CDPI et à d'autres comités et groupes de travail, au besoin, lorsqu'il s'agit d'examiner les orientations stratégiques et les enjeux du gouvernement en matière de TI.

8.2 Le ministère des Travaux publics et des Services gouvernementaux est un fournisseur clé de nombreux produits et services d'infrastructure de TI communs et partagés aux ministères. Il incombe au Ministère d'établir la gouvernance pour la prestation de ses services aux ministères clients.

8.3 Le Bureau du dirigeant principal des ressources humaines (BDPRH) du SCT a la responsabilité de conseiller et d'orienter les groupes intéressés à l'égard d'un vaste éventail de stratégies judicieuses en matière de gestion solide des ressources humaines (RH), notamment en ce qui concerne la planification intégrée des activités et des ressources humaines. Des représentants du Bureau sont à la disposition du SCT (DDPI) pour lui fournir des conseils sur les stratégies de recrutement et de maintien de l'effectif, et lui faire part de toute leçon apprise.

8.4 L'École de la fonction publique du Canada est responsable de l'élaboration et de l'exécution d'une stratégie et d'un programme d'apprentissage pangouvernemental de base, pour tous les fonctionnaires contribuant à la gestion des TI, qui sont conformes à la Politique en matière d'apprentissage, de formation et de perfectionnement et sont fondés sur des consultations tenues auprès des centres d'autorité fonctionnels pertinents.

9. Références

10. Demandes de renseignements

Veuillez adresser toute demande de renseignements au sujet de la présente directive au DPI du ministère ou l'équivalent. Pour obtenir de l'aide au sujet de l'interprétation de la présente directive, le DPI du ministère ou l'équivalent doit communiquer avec :

Direction du dirigeant principal de l'information
Secrétariat du Conseil du Trésor
Ottawa (Ontario)  K1A 0R5
 
Courriel : cio-dpi@tbs-sct.gc.ca
Téléphone : 613-946-5029
Télécopieur : 613-946-4334

Annexe A - Définitions

activité ( activity )
Travaux effectués pour réaliser un extrant comme un produit ou un service. Il s'agit d'une composante d'un programme qui peut comprendre plusieurs niveaux (par exemple, activité, sous-activité et sous-sous-activité) qui descendent jusqu'au niveau requis pour gérer un programme et ses services avec succès.
applications ( applications )
Sous-ensemble de logiciels qui utilisent toutes les fonctions d'un ordinateur directement pour exécuter la tâche désirée de l'utilisateur
biens ( assets )
Biens tangibles et intangibles de valeur dont la durée de vie dépasse un an, qu'ils soient détenus par l'État, prêtés ou que l'on y accède par le truchement d'autres arrangements
Conseil des dirigeants principaux de l'information (CDPI) ( Chief Information Officer Council [CIOC])
Forum permettant au dirigeant principal de l'information (DPI) du ministère ou l'équivalent de prendre part au processus décisionnel partagé en recommandant au DPI du Canada des options relatives aux technologies de l'information dans l'ensemble du gouvernement fédéral. Ce forum permet de s'assurer que les ministères appuient collectivement les décisions prises par le CDPI. Le mandat du CDPI donne des précisions sur les activités du CDPI.
client ( client )
Partie à laquelle le service est destiné. Il peut s'agir de clients externes (p. ex., des citoyens, des entreprises, des non-Canadiens ou des organismes sans but lucratif) ou internes (p. ex., des ministères).
COBIT ( CoBIT )
Signifie « Control Objectives for Information & related Technology » et représente un ensemble de pratiques exemplaires qui fournissent une orientation à la gestion des processus de TI. (Source : IT Governance Institute (en anglais) )
service commun ( common service )
Service fourni par un organisme de service commun
organisme de service commun ( common service organization )
Ministère ou organisme désigné comme fournisseur de services particuliers central qui appuient les exigences des ministères. L' appendice B de la Politique sur les services communs dresse une liste des organismes de services communs.
ministères ( departments )
A le même sens qu'à l'article 2 de la Loi sur la gestion des finances publiques et comprend l'ensemble des ministères, des organismes, des directions et des établissements publics énumérés aux annexes I, I.1 et II de la Loi.
DPI du ministère ou l'équivalent ( departmental CIO or equivalent )
Cadre supérieur désigné par l'administrateur général conformément à l' article 6.1.6 de la Politique sur la gestion des technologies de l'information pour représenter le ministère au SCT pour toutes les questions liées à la gestion des TI. Les exigences de la présente directive n'incluent pas toutes les fonctions et responsabilités du DPI du ministère ou l'équivalent; en plus de la gestion des TI, les autres responsabilités pourraient comprendre la gestion de l'information ou la sécurité des TI.
technologies de l'information ( information technology )
Concernent à la fois l'infrastructure technologique et les applications de TI. L'infrastructure technologique comprend tout matériel ou système utilisé pour l'acquisition, le stockage, la manipulation, la gestion, le déplacement, le contrôle, l'affichage, la commutation, les échanges, la transmission ou la réception automatique de données ou de renseignements. Les applications de TI comprennent la conception, le développement, l'installation et la mise en œuvre de systèmes et d'applications informatiques visant à satisfaire à des exigences opérationnelles.
investissement ( investment )
Utilisation de ressources dans l'attente de recevoir des bénéfices dans le futur tels qu'une augmentation de rendement, de revenus ou d'actifs ou l'acquisition de connaissances ou d'aptitudes.
interopérabilité ( interoperability )
Capacité qu'ont les ministères de fonctionner en synergie par le truchement de politiques, de pratiques, de processus et de technologies uniformes de gestion des TI
prise de décisions en matière de TI ( IT decision making )
Mesures et processus liés à la prise de décisions sur la gestion des TI.
services de TI ( IT services )
Services que les clients et les destinataires-utilisateurs finaux perçoivent comme les produits du fournisseur de services de TI. Les services peuvent être offerts par les fournisseurs au moyen d'une ou de plusieurs activités internes.
ITIL ( ITIL )
Signifie « Information Technology Infrastructure Library » et représente un ensemble de pratiques exemplaires qui orientent la gestion des services de TI. (Référence : ITIL (en anglais) )
gestion des technologies de l'information ( management of information technology )
Planification, acquisition, création, mise en œuvre et exploitation des biens, des systèmes ou des services de TI, la mesure de leur rendement et les modalités relatives à leur élimination.
service ( service )
Moyen, administré par un programme, servant à produire un extrant final valorisé en vue de répondre aux besoins d'un ou de plusieurs groupes cibles.
catalogue de services ( service catalogue )
Base de données ou document structuré publié par un fournisseur de services à l'intention des utilisateurs de services, qui donne une description complète des services de TI ou, à tout le moins, de l'information sur le coût, la qualité et les niveaux de service. Le catalogue de services peut aussi comprendre les processus de demande de services et les lieux de contact.
établissement du coût des services ( service costing )
Estimation de coûts qui aide la haute direction à prendre des décisions à l'égard des services (voir le Guide d'établissement des coûts du SCT)
service partagé ( shared service )
Service utilisé par plus d'un client.
petits ministères et organismes ( small departments and agencies )
Les organisations ayant des niveaux de référence de moins de 300 millions de dollars par année, y compris des recettes à valoir sur le crédit.
intervenant ( stakeholder )
Entité (p. ex., un citoyen, une entreprise, un fournisseur de services, un utilisateur de services, un partenaire ou un employé) du gouvernement fédéral ou de l'extérieur qui s'intéresse à un service, à un projet ou à une organisation de TI, ou aux activités, aux ressources ou aux produits connexes

Annexe B - Contenu du plan de TI et rapport sur le progrès des TI

12.1 Plan de TI

Le plan de TI est un document pratique qui définit les orientations, les stratégies, l'architecture et la capacité des ressources humaines des ministères en matière de TI, et la façon dont celles-ci s'harmonisent pour réaliser les activités ministérielles et les objectifs stratégiques pangouvernementaux. Le plan de TI appuiera l'affectation des ressources efficace et les décisions du ministère en matière de planification des investissements au moyen du processus ministériel de planification des investissements. Le plan de TI tient compte des priorités ministérielles et décrit les investissements prévus, y compris les services acquis, sur la prochaine période minimale de cinq ans, dans les domaines suivants :

  • nouveaux projets, systèmes ou services de TI, ou les améliorations importantes apportées aux projets, aux systèmes ou aux services existants;
  • maintenance ou améliorations prévues aux systèmes ou aux services de TI existants;
  • opérations de TI.

Le plan de TI fait l'objet d'un examen annuel et est mis à jour au besoin au moment de l'examen. Il traite au minimum de la gouvernance, des activités de TI, des mesures de performance et de la gestion des risques.

12.1.1 Gouvernance

  • La gouvernance comprend les processus décisionnels dans les secteurs suivants :
    • Stratégies et politiques en matière de TI
    • Infrastructure
    • Applications et systèmes
    • Affectation des ressources
  • Les décisions relatives à l'affectation des ressources en matière de TI sont orientées par les critères et la méthode de sélection et d'établissement des priorités de la direction.

12.1.2 Activités de TI

  • Les TI contribuent à la production de résultats opérationnels dans le contexte de l'article 12.1.
  • L'architecture des TI, y compris, mais sans s'y limiter, la définition des compétences de base en matière de TI, des choix et des services de technologie, devraient appuyer les résultats opérationnels.
  • Les TI devraient être harmonisées avec les priorités ministérielles et pangouvernementales en matière de TI, la technologie et les services communs et partagés, lorsque ceux-ci sont disponibles et pertinents.
  • Les objectifs en matière d'affectation des ressources doivent être classés dans quatre catégories :
    • Innovation – Affectation des ressources axée sur la transformation du modèle opérationnel du ministère;
    • Possibilité d'affaires – Affectation des ressources dans le but de procurer un avantage opérationnel mesurable (p. ex., la croissance du revenu ou des services);
    • Soutien – Affectation des ressources dans le but de maintenir les niveaux de service existants (p. ex., l'utilisation courante des TI);
    • Obligatoire – Affectation des ressources nécessaire pour se conformer aux lois ou aux règlements.

12.1.3 Mesure du rendement

  • Il faut produire des résultats opérationnels et des indicateurs de rendement clés pour mesurer la prestation des services de base.
  • Les mesures du rendement appuient l'amélioration continue en surveillant et en délimitant les activités de TI prévues.

12.1.4 La gestion des risques en matière de TI pour l'ensemble des activités prévues, lesquelles comprennent les processus et les stratégies utilisées pour gérer les éléments suivants :

  • affectation des ressources;
  • établissement du calendrier;
  • risques opérationnels (p. ex., confidentialité, intégrité, disponibilité de l'infrastructure et des services de base, et renouvellement de l'infrastructure);
  • capacité et durabilité.

12.2 Rapport de progrès en matière de TI

Le rapport de progrès annuel en matière de TI traite des progrès dans les activités prévues, de l'affectation des ressources et des changements dans le calendrier, ainsi que des recommandations liées au prochain cycle de planification.

Annexe C Procédures obligatoires pour l'évaluation de l'architecture intégrée

  • C.1Les présentes procédures entrent en vigueur le 1er décembre 2018.
  • C.2Procédures
    • C.2.1Les présentes procédures contiennent les détails des exigences énoncées à la section 6.1.1 de la Directive sur la gestion de la technologie de l'information.
    • C.2.2Les présentes procédures seront utilisées par le Comité d'examen de l'architecture ministérielle et le Comité d'examen de l'architecture intégrée du gouvernement du Canada comme cadre d'évaluation pour examiner les initiatives numériques visant à veiller à ce que le GC agisse comme une seule organisation et à assurer l'harmonisation ministérielle avec l'orientation numérique du gouvernement du Canada.
    • C.2.3Les procédures obligatoires sont les suivantes :
      • Architecture opérationnelle
        • C.2.3.1Se conformer au Modèle de capacité opérationnelle du GC.
          • C.2.3.1.1Définir les services du programme comme les capacités opérationnelles nécessaires pour établir un vocabulaire commun entre les opérations, le développement et l'exploitation.
          • C.2.3.1.2Déterminer les capacités qui sont communes à l'organisation du GC et qui peuvent être partagées et réutilisées.
          • C.2.3.1.3Modéliser les processus opérationnels à l'aide de la Notation de la gestion des processus opérationnels (NMPO) afin de déterminer les processus organisationnels communs.
        • C.2.3.2Concevoir en songeant avant tout aux utilisateurs et exécuter avec des équipes multidisciplinaires.
          • C.2.3.2.1Mettre l'accent sur les besoins des utilisateurs, utilisant des méthodes agiles, itératives et axées sur l'utilisateur.
          • C.2.3.2.2Respecter les exigences en matière d'accessibilité et de langues officielles.
          • C.2.3.2.3Inclure tous les ensembles de compétences requis pour la prestation des programmes, y compris pour les exigences, la conception, le développement et les opérations.
          • C.2.3.2.4Travailler tout au long du cycle de vie de l'application, de l'élaboration et de la mise à l'essai au déploiement et aux opérations.
          • C.2.3.2.5Veiller à ce que la qualité soit prise en compte tout au long du cycle de vie de développement des logiciels.
          • C.2.3.2.6Veiller à ce que la reddition de comptes pour la protection des renseignements personnels soit claire.
          • C.2.3.2.7Encourager et adopter le développement basé sur les tests (DBT) pour améliorer la confiance entre les entreprises et la TI.
        • C.2.3.3Concevoir les systèmes afin qu'ils soient mesurables et responsables
          • C.2.3.3.1Afficher les attentes en matière de rendement pour chacun des services de la TI.
          • C.2.3.3.2Rendre disponible une piste de vérification pour toutes les transactions afin d'assurer la responsabilisation et la non-répudiation.
          • C.2.3.3.3Établir des paramètres pour les opérations et la TI pour atteindre les résultats opérationnels.
          • C.2.3.3.4Appliquer la gestion de la surveillance et du cycle de vie aux investissements numériques par l'entremise de la gouvernance.
      • Architecture de l'information
        • C.2.3.4Collecte de données
          • C.2.3.4.1Veiller à ce que les données soient recueillies en vue de maximiser l'utilisation et la disponibilité des données.
          • C.2.3.4.22 Veiller à ce que les données recueillies s'harmonisent avec les normes organisationnelles et internationales.
          • C.2.3.4.3Si des normes organisationnelles ou internationales n'existent pas, élaborer des normes de façon transparente avec la collaboration des principaux experts en la matière.
          • C.2.3.4.4Veiller à ce que la collecte de données produise des données de haute qualité, conformément à des lignes directrices sur la qualité des données.
          • C.2.3.4.5Veiller à ce que les données soient recueillies au moyen de pratiques éthiques en appuyant l'utilisation appropriée axée sur les citoyens et les entreprises.
          • C.2.3.4.6Les données ne doivent être achetées qu'une seule fois et doivent s'harmoniser avec les normes internationales.
          • C.2.3.4.7Au besoin, assur la collaboration avec les responsables des données du ministère ou de l'organisation, les autres ordres de gouvernements, de même que les peuples autochtones.
        • C.2.3.5Gestion des données
          • C.2.3.5.1Faire preuve d'harmonisation avec la gouvernance et les stratégies liées aux données organisationnelles et ministérielles.
          • C.2.3.5.2Assurer la reddition de comptes pour les rôles et les responsabilités liées aux données.
          • C.2.3.5.3Concevoir afin de maximiser l'utilisation et la disponibilité des données.
        • C.2.3.6Stockage des données
          • C.2.3.6.1Veiller à ce que les données soient stockées de façon sécuritaire, conformément à la Stratégie nationale de cybersécurité, et à Loi sur la protection des renseignements personnels.
          • C.2.3.6.2Suivre les calendriers de conservation et d'élimination.
          • C.2.3.6.3Veiller à ce que les données soient stockées de manière à faciliter leur trouvabilité, leur accessibilité, et leur interopérabilité.
        • C.2.3.7Échange des données
          • C.2.3.7.1Les données doivent être partagées ouvertement par défaut conformément à la Directive sur le gouvernement ouvert.
          • C.2.3.7.2Veiller à ce que les données détenues par le gouvernement puissent être combinées avec des données provenant d'autres sources pour favoriser l'interopérabilité et la possibilité d'interprétation aux fins d'utilisation interne et externe.
          • C.2.3.7.3Réduire la collecte de données redondantes.
          • C.2.3.7.4Réutiliser les données existantes dans la mesure du possible.
          • C.2.3.7.5Encourager l'échange de données et la collaboration.
      • Architecture des applications
        • C.2.3.8Utiliser des normes et des solutions ouvertes par défaut
          • C.2.3.8.1Dans la mesure du possible, privilégier des normes ouvertes et des logiciels libres.
          • C.2.3.8.2Si une version en source ouverte n'est pas disponible ou ne satisfait pas aux besoins des utilisateurs, privilégier les logiciels disponibles sur le marché (LDSM) indépendants des plateformes plutôt que les LDSM exclusifs. Ainsi, l'on évite de dépendre d'une technologie particulière et l'on gagne en substituabilité et en interopérabilité.
          • C.2.3.8.3Si l'on doit opter pour une solution faite sur mesure, tout code source rédigé par le gouvernement du Canada doit être diffusé en format ouvert par l'entremise des sites Web et des services du gouvernement du Canada désignés par le Secrétariat du Conseil du Trésor du Canada.
          • C.2.3.8.4Tout code source doit être diffusé et assorti d'une licence de logiciel à source ouverte
          • C.2.3.8.5Exposer les données publiques pour mettre en œuvre les initiatives Données ouvertes et Information ouverte
        • C.2.3.9Maximiser la réutilisation
          • C.2.3.9.1Tirer parti des solutions, des composantes et des processus existants et les réutiliser.
          • C.2.3.9.2Choisir des solutions organisationnelles et de grappe plutôt que des solutions propres aux ministères.
          • C.2.3.9.3Atteindre la simplification en réduisant au minimum le dédoublement des composantes et en adhérant aux normes pertinentes.
          • C.2.3.9.4Informer le Comité d'examen de l'architecture intégrée du gouvernement du Canada GC au sujet des investissements et des innovations ministérielles.
          • C.2.3.9.5Partager publiquement le code lorsque cela est approprié, et lorsqu'il n'est pas possible de le faire, le partager au sein du gouvernement du Canada.
        • C.2.3.10Permettre l'interopérabilité
          • C.2.3.10.1Exposer toutes les fonctionnalités en tant que services.
          • C.2.3.10.2Utiliser des microservices reposant sur les capacités organisationnelles. Étendre chaque service à une seule finalité.
          • C.2.3.10.3Exécuter chaque service de la TI dans son propre processus et communiquer avec d'autres services de la TI au moyen d'une interface bien définie, comme une interface de programmation d'applications (API), conformément à l'annexe D : Procédures obligatoires pour les interfaces de programmation d'applications.
          • C.2.3.10.4Exécuter les applications dans des contenants.
          • C.2.3.10.5Tirer parti de la Plateforme d'échange numérique du GC pour les composantes comme le magasin d'API, la messagerie et le Bus de service du GC.
      • Architecture de la technologie
        • C.2.3.11Utiliser les nuages d'abord
          • C.2.3.11.1Appliquer cet ordre de préférence : Logiciel en tant que service (SaaS) d'abord, puis Plateforme comme service (PaaS), et enfin Infrastructure comme service (IaaS).
          • C.2.3.11.2Appliquer cet ordre de préférence : Informatique en nuage d'abord, puis nuage hybride, puis nuage privé, et enfin des solutions sans nuages (sur place).
          • C.2.3.11.3Concevoir en fonction de la mobilité des nuages et élaborer une stratégie de sortie pour éviter l'asservissement à un seul fournisseur.
        • C.2.3.12Concevoir en visant le rendement, la disponibilité et l'extensibilité
          • C.2.3.12.1Concevoir en visant la résilience.
          • C.2.3.12.2Veiller à ce que les délais de réponse répondent aux besoins de disponibilité des utilisateurs.
          • C.2.3.12.3Appuyer les déploiements sans arrêt de service pour les travaux d'entretien prévus et non prévus.
          • C.2.3.12.4Utiliser les architectures réparties, présumer que la défaillance se produira, traiter les erreurs avec élégance, et surveiller activement.
      • Architecture de la sécurité et protection des renseignements personnels
        • C.2.3.13Concevoir en visant la sécurité et la protection des renseignements personnels
          • C.2.3.13.1Mettre en œuvre la sécurité à travers toutes les couches d'architecture.
          • C.2.3.13.2Classer correctement les données afin de déterminer les mesures de protection appropriées.
          • C.2.3.13.3Effectuer une évaluation des facteurs relatifs à la vie privée (ÉFVP) et d'atténuer les risques relatifs à la vie privée lorsque des renseignements personnels sont en cause.
          • C.2.3.13.4Équilibrer les besoins des utilisateurs et opérationnels avec des mesures de sécurité proportionnelles et des mécanismes adéquats de protection de la vie privée.

Annexe D - Procédures obligatoires pour les interfaces de programmation d'applications

  • D.1 Date d'entrée en vigueur
    • D.1.1Les présentes procédures entrent en vigueur le 1er décembre 2018.
  • D.2 Procédures
    • D.2.1Les présentes procédures contiennent les détails des exigences énoncées à la section 6 de la Directive sur la gestion de la technologie de l'information.
    • D.2.2Voici les procédures obligatoires :
      • D.2.2.1Suivez les normes relatives au numérique du gouvernement du Canada – Les API doivent être développées en respectant les normes relatives au numérique du gouvernement du Canada, plus précisément :
        • D.2.2.1.1Concevez avec les utilisateurs en effectuant ce qui suit :
          • D.2.2.1.1.1Collaborez avec des développeurs qui sont censés utiliser votre API afin de veiller à ce que les spécifications de l'interface répondent à leurs besoins et tiennent compte de leurs contraintes ou limites.
          • D.2.2.1.1.2Élaborez des API en fonction des exigences opérationnelles que les systèmes consommateurs sont censés appuyer et non pas les structures de données principales auxquelles ils ont accès.
        • D.2.2.1.2D.2.2.1.2 Permettez au personnel d'offrir de meilleurs services en effectuant ce qui suit :
          • D.2.2.1.2.1Veillez à ce que les outils, la formation et les processus nécessaires soient en place pour appuyer un processus robuste et souple d'élaboration et de gestion du cycle de vie des API.
          • D.2.2.1.2.2Adoptez des pratiques d'intégration et de prestation continues (CI/CD) et de développement axé sur les essais (DAE) appuyées par des outils d'automatisation et des essais de sécurité intégrés. Cela constitue la base de l'adoption de DevOps à mesure que la maturité s'améliore.
        • D.2.2.1.3Travaillez de manière ouverte par défaut en effectuant ce qui suit :
          • D.2.2.1.3.1Élaborez des API qui peuvent être utilisées publiquement et permettre la réutilisation, lorsque vous travaillez avec des données de nature non délicates.
        • D.2.2.1.4Utilisez des normes et des solutions ouvertes en effectuant ce qui suit :
          • D.2.2.1.4.1Exposez les API au moyen de normes ouvertes acceptées par l'industrie, tandis que les protocoles prioritaires des fournisseurs et les schémas de données doivent être évités.
          • D.2.2.1.4.2Tirez parti des outils et des cadres de sources ouvertes pour mettre en œuvre l'API dans la mesure du possible.
        • D.2.2.1.5Effectuez des itérations et des améliorations constantes en effectuant ce qui suit :
          • D.2.2.1.5.1Concevez des API en gardant à l'esprit la réutilisation, mais il ne faut pas prévoir ou deviner les besoins futurs.
          • D.2.2.1.5.2Veillez à ce que les API soient conçues de manière à permettre des itérations à mesure que de nouvelles exigences et de nouveaux cas d'utilisation apparaissent, tout en offrant un niveau raisonnable de rétrocompatibilité.
      • D.2.2.2Élaborez des API en suivant le modèle de transfert d'état représentationnel (REST) par défaut. REST est effectivement la norme pour l'intégration avec les services d'informatique en nuage et est également la norme établie par la majorité des autres gouvernements ayant des programmes d'API bien établis. Suivez les pratiques exemplaires de l'industrie lors de la conception et l'élaboration de votre API REST en effectuant ce qui suit :
        • D.2.2.2.1Représentez les ressources sous forme de localisateurs de ressources uniformes (URL) en veillant à ce que les URL représentent les entités et les objets d'affaires, et non les opérations sur ces entités et objets (c'est-à-dire, éviter les verbes à l'intérieur de la chaîne URL).
        • D.2.2.2.2Utilisez la notation des objets du langage Java (JSON) et d'autres représentations fondées sur JSON (p. ex., JSON-LD) comme la structure de message dans la mesure du possible et appliquer les pratiques suivantes :
          • D.2.2.2.2.1Formez les réponses comme un objet JSON et non comme un tableau. Les tableaux peuvent limiter la capacité d'inclure des métadonnées sur les résultats et limiter la capacité des API d'ajouter d'autres clés de haut niveau à l'avenir.
          • D.2.2.2.2.2Éviter les touches d'objet imprévisibles (c'est-à-dire, dynamiques) comme celles qui découlent des données, car cela ajoute une certaine friction pour les clients.
          • D.2.2.2.2.3Choisissez un seul cas de grammaire pour les clés d'objet, comme « soulignage » ou « casse de chameau », et l'utiliser de façon uniforme.
        • D.2.2.2.3Veillez à ce que chaque verbe représente une seule opération sur une ressource donnée et évitez d'utiliser des paramètres de demande pour exécuter d'autres opérations. Toutefois, voici les utilisations appropriées des verbes du protocole de transfert hypertexte (HTTP) dans le contexte d'une API REST :

          GET (OBTENIR) (extraire ou interroger une ressource);

          POST (AFFICHER) (créer une nouvelle ressource ou lancer une action);

          PUT (METTRE) (mettre à jour ou remplacer une ressource existante);

          DELETE (SUPPRIMER) (supprimer une ressource).

        • D.2.2.2.4Utilisez des identificateurs de ressource uniformes (URI) pour identifier de façon unique des données qui sont retournées dans le cadre d'une réponse afin d'y exécuter des opérations futures, et les itérations peuvent tirer profit des ressources existantes avec une reprise minimale.
        • D.2.2.2.5La négociation de contenu doit se faire à l'aide de l'approche axée sur les agents au moyen des en-têtes HTTP, y compris :
          • D.2.2.2.5.1Les en-têtes de demande ACCEPT (ACCEPTER) et CONTENT-TYPE (TYPE DE CONTENU) sont obligatoires.
          • D.2.2.2.5.2L'en-tête autorisation (AUTORISATION) est obligatoire pour les API sécurisées.
          • D.2.2.2.5.3On doit utiliser la touche de l'API dans l'en-tête plutôt que l'URI.
          • D.2.2.2.5.4On doit configurer les clés ou jetons d'API de façon sécuritaire et les utiliser de façon appropriée.
          • D.2.2.2.5.5La réponse doit contenir l'en-tête TYPE DE CONTENU.
        • D.2.2.2.5.6Publiez à l'aide des API du protocole simple d'accès aux objets (SOAP) ou du langage de balisage extensible (XML) s'il y a des contraintes techniques du côté du fournisseur ou du consommateur. Tous les points d'extrémité de SOAP doivent respecter les spécifications de la version 1.2 de SOAP (en anglais seulement) et être conformes à la version 2.0 du WS-I Basic Profile (en anglais seulement).
      • D.2.2.3Veillez à ce que les API répondent avec des schémas de messages qui sont bien définis, faciles à comprendre, et à utiliser en appliquant les pratiques suivantes :
        • D.2.2.3.1Tirez parti des modèles d'information communs reconnus par l'industrie (p. ex., NIEM, RH-JSON, HL7) dans la mesure du possible. Si vous devez définir votre propre modèle d'information, créez un modèle qui est neutre sur le plan de la technologie et de la plateforme plutôt que de simplement réutiliser un schéma prioritaire du fournisseur. L'utilisation appropriée des modèles d'information communs doit respecter les normes en matière de données du gouvernement du Canada.
        • D.2.2.3.2L'exposition des structures de données brutes (p. ex., les ensembles de rangées, les ensembles de tableaux, LDAP DN) des systèmes principaux doit être limitée aux API de données ouvertes, de rapports et aux API statistiques seulement, et strictement interdite dans les API de données principales, transactionnelles ou commerciales. Les API doivent résumer la représentation des données physiques principales du consommateur.
        • D.2.2.3.3Évitez les structures de données relationnelles comme JSON et XML puisqu'elles sont des structures de données hiérarchiques qui ne conviennent pas bien à la représentation des données relationnelles. Les schémas de données relationnelles doivent être écrasés en fonction du point de vue du consommateur de l'API.
        • D.2.2.3.4Veillez à ce que les contraintes d'un schéma de données soient évidentes lors de la lecture de la définition du schéma. Les structures de données génériques comme les paires clé-valeur et les champs génériques sont interdites en raison de l'incapacité de tester la compatibilité de l'API au niveau du contrat.
        • D.2.2.3.5Évitez de créer des codes d'erreur et des schémas personnalisés qui exigent une analyse approfondie par le système de consommation. Conformez-vous aux codes d'état HTTP (en anglais seulement) au moment de la construction de l'API REST et conformez-vous aux défectuosités de la version 1.2 de SOAP (en anglais seulement) au moment de la création de l'API SOAP.
        • D.2.2.3.6Résumez des détails techniques internes selon lesquels les réponses, y compris les messages d'erreur, doivent résumer les détails techniques dans lesquels le consommateur de l'API n'a aucune visibilité. Les erreurs techniques internes, les listes des unités d'exécution et les identificateurs de processus, entre autres, doivent tous être tenus à l'écart des données de réponse.
        • D.2.2.3.7Veillez à ce que l'interaction entre le consommateur et le fournisseur de l'API soit sans état. On ne doit s'attendre à aucun concept de séance ou de gestion de l'état de la part du consommateur en ce qui a trait à l'API (p. ex., réussite d'une séance d'identification). Toute interaction où de multiples API sont appelées dans une séquence reproductible pour créer une interaction commerciale unique doit être mise en œuvre comme une API détaillée afin d'éviter le fardeau de l'orchestration concernant le consommateur.
      • D.2.2.4Validez votre conception de l'API en l'utilisant avec une application de production au sein de votre organisation.
        • D.2.2.4.1Créez une fois pour plusieurs canaux en concevant des API afin qu'elles puissent être utilisées par les systèmes internes du gouvernement du Canada, les partenaires de confiance et les parties externes (c'est-à-dire, le public). La conception doit permettre d'appliquer différents profils d'accès aux données, soit à l'API, soit à une couche mandataire, sans qu'il soit nécessaire de créer d'autres API.
        • D.2.2.4.2Lancez un projet-pilote interne d'abord en élaborant des API parallèlement à un cas d'utilisation interne qui s'intégrerait dans l'API et utiliser ce projet-pilote interne pour valider la mise en œuvre de l'API avant de le publier aux fins d'utilisation externe.
      • D.2.2.5Assurez-vous de la sécurité de l'API lorsque l'on conçoit et met en œuvre une API qui donne accès à des données protégées ou privilégiées. Au moins, les pratiques de contrôle de sécurité suivantes doivent être suivies pour toute API autre que celles qui exposent des données publiques (p. ex., des données ouvertes).
        • D.2.2.5.1Appliquez les communications protégées en veillant à ce que les données de nature délicate ne soient jamais envoyées au moyen d'une connexion non sécurisée ou non chiffrée, et dans la mesure du possible, les données de nature non délicate doivent aussi être envoyées au moyen d'une connexion sécurisée. Activez le protocole TLS 1.2 ou des versions ultérieures, conformément aux directives du CST.
        • D.2.2.5.2Concevez des API pour résister aux attaques en veillant à ce que toutes les API soient conçues et mises en œuvre pour résister aux attaques courantes d'API comme les débordements de tampon et l'injection SQL. Traitez toutes les données présentées comme non fiables et validez-les avant le traitement. Tirer parti du schéma et des modèles de données pour veiller à la bonne validation des données.
        • D.2.2.5.3N'incluez pas des données de nature délicate dans les URL de demande puisque les chaînes d'URL peuvent être suivies et compromises, même avec un chiffrement de transport. Si une requête comporte des éléments de données de nature délicate (p. ex., le numéro d'assurance sociale), transmettez les paramètres de requête comme une charge utile de message JSON plutôt que dans la chaîne de demande d'URL.
        • D.2.2.5.4Protégez l'accès aux API en mettant en œuvre une stratégie de contrôle de l'accès qui protège les API d'un mauvais appel, y compris des références de fonction et de données non autorisées. Autorisez et authentifiez toujours avant toute opération pour veiller à ce que les API soient restreintes aux personnes ou aux systèmes autorisés. Utiliser des normes ouvertes comme OpenID Connect et Open Authorisation 2.0 (OAuth 2.0) pour les API REST, et le langage SAML 2.0 (Security Assertion Markup Language 2.0) pour les API SOAP. Veillez à ce que la clé ou le secret API soit bien protégé. Les API de données ouvertes doivent être sécurisées avec une clé API pour permettre le suivi de l'utilisation et fournir la capacité de déterminer et d'éviter des utilisations malveillantes. Les API de données ouvertes doivent être sécurisées avec une clé API pour permettre le suivi de l'utilisation et fournir la capacité de déterminer et d'éviter des utilisations malveillantes.
        • D.2.2.5.5Appliquez les pratiques sécuritaires en matière de gestion des jetons selon lesquelles l'authentification fondée sur le jeton est fortement recommandée et est obligatoire pour toutes API publiées d'être utilisées à l'échelle du gouvernement du Canada ou à l'extérieur. Utilisez des jetons standard de l'industrie; ne créez pas de jetons personnalisés; évitez d'utiliser des systèmes de jetons exclusifs aux fournisseurs. JSON Web Token (JWT) (en anglais seulement) est requis pour les interactions API REST. WS-Security SAML Token Profile (en anglais seulement) est requis pour les API SOAP. Tous les jetons d'accès doivent expirer dans un délai raisonnable (c'est-à-dire, moins de 24 heures). Dans le cas du SAML, l'expiration de l'assertion doit être fixée de façon à contrôler la période de validité de toute la séance d'authentification et d'autorisation.
        • D.2.2.5.6Utilisez des passerelles et des données de substitution plutôt que des listes blanches lorsque vous exposez des API à Internet. Utilisez une couche de passerelle sécurisée pour fournir un point de contrôle de sécurité au lieu de simplement envoyer une liste blanche d'adresses IP (protocole Internet) entrantes. La fonction de passerelle du magasin d'API peut être utilisée. Lorsque vous utilisez des API externes, la route passe par des mandataires (sortie) au lieu d'utiliser une liste blanche d'adresses IP sur le pare-feu sortant.
        • D.2.2.5.7Intégrez et automatisez les essais de sécurité pour valider tous nouveaux changements au code source de l'API et pour assurer la robustesse des changements demandés. Évaluez l'incidence du changement et effectuez des essais en conséquence. Des audits périodiques de l'accès de l'API peuvent être nécessaires, selon la nature des données et son utilisation.
        • D.2.2.5.8Vérifiez l'accès aux données de nature délicate selon lequel l'accès aux API traitant de données de nature délicate ou personnelle doit être consigné pour un audit ultérieur et examiné régulièrement. Les journaux d'accès doivent inclure au moins le système et les identificateurs individuels qui tentent d'accéder à l'API ainsi que l'horodatage.
        • D.2.2.5.9Consignez et surveillez le rendement et l'activité en faisant le suivi de l'utilisation et en surveillant les activités suspectes anormales y compris les profils d'accès comme les demandes après les heures normales, les demandes de données volumineuses, entre autres. Utilisez les normes de consignation (p. ex., format d'événement commun) et intégrez les journaux de façon centralisée. Déterminez les dépendances et surveillez les vulnérabilités, surtout celles pour les exécutions téléchargées qui fonctionnent dans le cadre de l'API. Les événements suspects doivent être envoyés à la capacité ou à l'autorité appropriée des opérations de sécurité conformément aux politiques sur la cybersécurité du gouvernement du Canada et au Plan de gestion des événements de cybersécurité du gouvernement du Canada.
      • D.2.2.6Utilisez un encodage et des métadonnées uniformes afin de veiller à ce que les API soient interopérables dans les organisations et à ce que vous mainteniez l'uniformité des données en mettant en œuvre les pratiques suivantes à la définition de l'API :
        • D.2.2.6.1Utilisez Unicode Transformation Format-8 (UTF-8) comme étant le type de codage standard pour tous les textes et toutes les représentations textuelles des données par API. Ce processus doit être respecté pour toutes les API publiées à l'échelle du GC et à l'externe. D'autres codages peuvent être utilisés à des fins uniques et/ou dans des API intraorganisationnelles seulement, s'il y a des limites techniques à l'utilisation de UTF-8.
        • D.2.2.6.2Utilisez le format de date uniforme de l'Organisation internationale de normalisation 8601 (ISO 8601), en temps universel coordonné (UTC), comme le format de date et heure standard pour les champs de données et d'horodatage dans les API publiées dans l'ensemble du GC et à l'externe. Le format de la date est <aaaa-mm-jj> tandis que le format de l'horodatage est <yyyy-mm-dd>T<hh:mm:ss>Z. Toute autre représentation du temps dans le système source doit être convertie à ce format par l'API.
        • D.2.2.6.3Appuyez les langues officielles de sorte que tout le contenu en français ou en anglais retourné comme données doit être imbriqué avec les codes de langue BCP-47 utilisés comme des touches, en particulier « fr » et « en ». Les API externes doivent répondre avec du contenu dans la langue demandée si les données principales l'appuient. Les API doivent interpréter l'en-tête HTTP ACCEPT-LANGUAGE (ACCEPTER LA LANGUE) et rendre le contenu approprié. Si l'en-tête n'est pas établi, le contenu dans les deux langues doit apparaître. Dans le cas des données et des systèmes unilingues, il faut déployer tous les efforts possibles afin de veiller à ce que la langue soit bien indiquée dans le message de réponse.
      • D.2.2.7Améliorez et appuyez l'API tout au long de son cycle de vie en effectuant ce qui suit :
        • D.2.2.7.1Créez de façon itérative en lançant de nouvelles versions de l'API à mesure que les exigences changent ou que de nouvelles exigences sont introduites. Sollicitez activement la rétroaction des consommateurs de l'API pour comprendre si l'API offre une valeur appropriée et apportez des modifications dans les itérations futures.
          • D.2.2.7.1.1Modifiez chaque changement à l'API aussi petit soit-il, en suivant la structure de création de versions v<Majeur>.<Mineur>.<Correctif> suivant la structure selon laquelle :
            • Majeur = Lancement important susceptible de rompre la rétrocompatibilité.
            • Mineur = Ajout d'attributs facultatifs ou de nouvelles fonctionnalités qui sont rétrocompatibles, mais qui doivent être mises à l'essai.
            • Correctif = Solution interne qui ne devrait pas avoir d'incidence sur le schéma et/ou le contrat de l'API.

            Par exemple, passer de la v1.1.0 à la v1.1.1 permettrait une simple mise à niveau déployé en place puisqu'il s'agit d'une rustine, tandis que passer de la v1.1.0 à la v2.0.0 serait une importante diffusion et exigerait que l'ancienne version soit conservée pendant que les consommateurs font l'essai de la nouvelle version et migrent vers cette dernière.

          • D.2.2.7.1.2L'URL doit être le reflet de la version principale seulement (p. ex., v3). Les versions ne doivent pas être passées en paramètre ou dans l'en-tête de la demande pour forcer le consommateur de l'API à identifier explicitement la version et pour éviter de passer par défaut à une version incompatible. Les versions mineures et les versions de la rustine n'ont pas besoin d'être dans l'URL puisqu'elles ne doivent pas rompre la rétrocompatibilité, mais elles doivent être clairement identifiées dans le contrat, la documentation de l'interface, et le message de réponse.
        • D.2.2.7.2Respectez les dépendances actuelles des consommateurs en appuyant au moins une version principale précédente (c'est-à-dire, N-1) afin de veiller à ce que les systèmes consommateurs aient le temps de migrer vers la dernière version de l'API. Communiquez votre feuille de route de développement aux équipes de consommateurs et travaillez avec elles pour comprendre l'incidence de tout changement majeur. Établissez des politiques de dépréciation et des calendriers clairs dès le départ afin que les consommateurs comprennent combien de temps ils doivent passer à chaque nouveau lancement avant que l'ancienne version ne soit mise hors ligne. Coordonnez les essais nécessaires sur tous les lancements mineurs et majeurs.
        • D.2.2.7.3Publiez un point de contact désigné à toutes les équipes qui utilisent votre API dans le magasin d'API. Si l'API est publiée pour une utilisation pangouvernementale ou externe, publiez un compte de courriel de soutien. Un numéro de téléphone doit également être fourni pour les API de très grande criticité.
        • D.2.2.7.4Chaque API doit être accompagnée d'un accord sur les niveaux de service (ANS) clairement défini. À tout le moins, l'ANS doit définir ce qui suit :
          • Heures de soutien (p. ex., 24 heures sur 24, de 9 h à 17 h, heures de bureau d'un océan à l'autre.)
          • Disponibilité du service (p. ex., 99 %.)
          • Temps de réponse du soutien (p. ex., dans l'heure, 24 heures, meilleur effort.)
          • Pannes prévues (p. ex., nuit, semaine, tous les deux dimanches en soirée.)
          • Limite du débit de traitement (p. ex., 100 demandes par seconde par consommateur.)
          • Limite de taille du message (p. ex., < 1 Mo par demande.)
      • D.2.2.8Mesurez et publiez les références de l'API selon lesquelles l'API doit faire l'objet d'une analyse comparative périodiquement afin de veiller à ce que le rendement et la capacité répondent continuellement aux besoins opérationnels actuels et prévus. Les mesures suivantes doivent être prises :
        • D.2.2.8.1Exécutez des essais du rendement et de charge sur l'API pour déterminer le temps de réponse et le débit de traitement pendant une charge raisonnable, ainsi que pour déterminer les seuils de rendement au-delà desquels l'API devient instable. Les essais de rendement doivent être intégrés au cycle de développement, de préférence par l'entremise d'un pipeline CI/CD automatisé afin de veiller à ce qu'ils soient effectués sur chaque nouvelle version.
        • D.2.2.8.2Les sommaires du rendement (p. ex., le temps de réponse moyen et le débit de traitement associé, le débit de traitement maximal stable) doivent être publiés en même temps que le contrat de l'API et l'accord sur les niveaux de service (ANS). Cette information doit être mise à jour pour chaque version.
        • D.2.2.8.3Le rendement de l'exécution doit faire l'objet d'un suivi et d'établissement de rapports afin de cerner les tendances et de veiller à ce que l'API ait la capacité nécessaire pour répondre à la demande d'utilisation.
        • D.2.2.8.4Des mécanismes de ralentissement artificiel doivent être mis en place pour contrôler le débit de traitement par rapport à l'ANS énoncé afin de prévenir les pics imprévus d'activité. Il vaut mieux rejeter les demandes qui dépassent les limites de débit de traitement prédéfinies que de laisser l'API s'effondrer.
      • D.2.2.9Utilisez et concevez des API raisonnablement en reconnaissant que les API ne sont pas la solution à tous les scénarios d'intégration. Il faut tenir compte des suivants lorsqu'on décide de mettre en œuvre une API et de concevoir les types de demandes qui sont autorisés afin de veiller à ce que l'architecture d'intégration soit appropriée et durable :
        • D.2.2.9.1Les API fondées sur la recherche (modèle de traction) sont préférables aux API fondées sur les collecteurs de données (modèle de poussée). Le fait que les systèmes utilisateurs interrogent les API en fonction de paramètres précis garantit que seules les données requises dans le contexte d'un processus opérationnel ou d'une transaction sont transmises. Cette approche permet également de veiller à ce que l'accès aux données puisse être mieux contrôlé du point de vue de la sécurité. Les API des contrôleurs de données favorisent la synchronisation et la prolifération des données de masse, ce qui est l'antithèse de l'architecture axée sur les API. Les techniques et outils d'intégration de données en lots doivent être utilisés pour les modèles de synchronisation de données et seulement lorsque cela est absolument nécessaire.
        • D.2.2.9.2Limitez l'utilisation des interrogations avec des caractères de remplacement dans les API puisqu'ils peuvent être dangereux du point de vue du rendement des données. Si les caractères de remplacement sont permis, veillez à ce qu'il y ait des limites quant au nombre de paramètres qui peuvent comporter une entrée de caractère de remplacement afin d'empêcher les recherches de données de grande taille. Il est beaucoup plus sécuritaire de rejeter une recherche comportant trop de caractères de remplacement que de mettre fin à une séance en effectuant une recherche dans la base de données du système principal.
        • D.2.2.9.3Les API qui exposent de grands jeux de données doivent appuyer une certaine forme de segmentation des données. Voici quelques modèles courants de pagination ainsi que des cas d'utilisation appropriés :
          • page et par page – Il est préférable de l'utiliser pour naviguer dans de grands jeux de données statiques (p. ex., des données de référence) où le même jeu de données est susceptible d'être retourné en raison de la même référence de page au fil du temps.
          • décalage et limite – Il est préférable de l'utiliser pour les API dont les systèmes principaux sont fondés sur le langage d'interrogation structuré (SQL), où le décalage représente le curseur de données d'une colonne indexée donnée.
          • depuis et limite – Il est préférable de l'utiliser pour les requêtes où le consommateur s'intéresse au delta, puisque la dernière requête et la structure de données du système principal sont indexées en fonction du temps.
        • D.2.2.9.4La capacité d'injecter des chaînes ou des objets de requête définis par le consommateur dans une API doit être limitée aux API de données ouvertes, de rapports et de statistiques seulement, et strictement interdite dans les API de données de référence, transactionnelles ou commerciales. Les requêtes dynamiques et ouvertes créent des surfaces d'attaque dangereuses pour les API. Il est préférable d'investir plus d'efforts dans l'identification de tous les cas d'utilisation d'interrogation valides et de concevoir l'API pour y répondre spécifiquement. Le GraphQL peut être utilisé à des fins statistiques, analytiques et d'établissement de rapports, mais ne doit pas être utilisé pour appuyer les opérations opérationnelles. OData ne doit être utilisé que si le système principal comporte des limites techniques et seulement pour les API internes d'une organisation.
        • D.2.2.9.5Appliquez des considérations spéciales pour les jeux de données en lots puisqu'il y aura des scénarios où les API devront contribuer à la mise à disposition des jeux de données en vrac entre les systèmes ou au public. Dans ces scénarios, il faut tenir compte des facteurs suivants :
          • D.2.2.9.5.1Les jeux de données plus petits doivent être retournés dans des formats comportant un faible temps système requis (p. ex., valeurs séparées par des virgules (CSV) ou JSON) plutôt que XML. Il faut éviter d'utiliser des fichiers joints comprimés, surtout lorsqu'on utilise des API externes, car ils peuvent contourner les mécanismes de balayage de contenu malveillant.
          • D.2.2.9.5.2Une API peut être mise en œuvre comme déclencheur pour lancer une interface hors bande (p. ex., transfert de fichiers géré) plus appropriée pour le déplacement de grands volumes de données.
          • D.2.2.9.5.3Si le jeu de données est publié sur des serveurs de fichiers déjà disponibles pour le consommateur, une API pourrait être mise en œuvre pour retourner un lien vers un fichier particulier en fonction de paramètres de demande particuliers.
      • D.2.2.10Les API doivent être publiées pour être trouvables. On doit documenter clairement la façon dont chaque API doit être utilisée. La documentation doit être concise et à jour. Les pratiques suivantes doivent être respectées afin de veiller à ce que les API soient documentées de façon appropriée sans que le fardeau de la gestion des documents d'accompagnement soit trop lourd :
        • D.2.2.10.1Toutes les API doivent être publiées dans le magasin de l'API aux fins de la découverte et de la gestion du cycle de vie. Les API doivent être convenablement étiquetées pour indiquer si elles sont pour l'utilisation intraministérielle, interne du gouvernement du Canada, ou publique.
        • D.2.2.10.2Utilisation OpenAPI, une spécification d'interface lisible par machine pour les API REST, pour consigner les contrats d'API REST. Il existe des outils à source ouverte (p. ex., Swagger – en anglais seulement) qui peuvent ensuite produire de la documentation lisible par l'humain à partir de cette spécification, ce qui évite la nécessité de créer et de maintenir une documentation distincte.
        • D.2.2.10.3Chaque API SOAP doit être accompagnée d'un contrat de langage de description de services Web (WSDL). Le WSDL est une spécification lisible par machine qui permet au développeur du consommateur de l'API de générer le code du consommateur.
        • D.2.2.10.4Publiez les essais unitaires et les données d'essai comme la façon la plus efficace de consigner ce qu'une API doit faire, accompagnés du contrat de l'API. Cela devient plus facile si la méthodologie de TDD a été suivie au cours de l'élaboration de l'API.
        • D.2.2.10.5Évitez les documents d'accompagnement volumineux. La nécessité d'un grand document distinct expliquant chaque méthode et chaque attribut indique habituellement que l'API est trop volumineuse, générique ou complexe. Envisagez de diviser l'API en composantes plus petites et de limiter la structure des messages.

© Sa Majesté la Reine du chef du Canada, représentée par le président du Conseil du Trésor, 2017,
ISBN : 978-0-660-09659-9

Date de modification :