Archivée [2020-03-31] - Directive sur la gestion des technologies de l'information

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

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.

• 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.

• D.1 Date d'entrée en vigueur
  
  • D.1.1Les présentes procédures entrent en vigueur le 1^er 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.