Série de documents sur la Stratégie d’architecture axée sur le service - Gouvernement du Canada - Guide d’introduction

Documents précédents

SCT SGDDI 379503

Personnes-ressources

Secrétariat du Conseil du Trésor, DDPI

Wesley McGregor
Architecte de la technologie, Gouvernement du Canada
Division de l’architecture intégrée et des normes
mcgregor.wesley@tbs-sct.gc.ca

Richard Bryson
Directeur principal, Secteurs de l’architecture
Division de l’architecture intégrée et des normes
bryson.richard@tbs-sct.gc.ca

Gary Doucet
Architecte en chef, Gouvernement du Canada
Directeur administratif
Division de l’architecture intégrée et des normes
doucet.gary@tbs-sct.gc.ca

Table des matières

1.0 - Avant-propos.

2.0 - À propos de ce document

2.1 - Objet

2.2 - Groupes cibles.

2.3 - Champ d’application.

3.0 - Aperçu de l’AAS du GC.

3.1 - Introduction.

3.2 - Positionner le cadre de fonctionnement

3.3 - Calculer la valeur de l’AAS du GC.

4.0 - Les trois couches de l’AAS du GC.

4.1 - Les avantages d’une structuration en couches.

4.2 - Les différentes couches.

4.2.1 - Architecture à composantes technologiques - Couche 1.

4.2.2 - Architecture d’échange de services - Couche 2.

4.2.3 - Architecture d’application de gestion - Couche 3.

4.3 - Autre point de vue sur les trois (3) couches.

5.0 - Transition vers l’AAS..

6.0 - Étapes suivantes.

7.0 - Annexes.

7.1 - Acronymes et abréviations.

Table des figures

Figure 1 - Lien entre l’AAS du GC et le MRSGC.

Figure 2 - Processus de négociation du service.

Figure 3 - Les trois couches de l’AAS du GC.

Figure 4 - Architecture à composantes technologiques (ACT) - Couche 1 de l’AAS du GC.

Figure 5 - Architecture d’échange de services (AES)  - Couche 2 de l’AAS du GC.

Figure 6 - Anneau des services communs de l’ACT à l’AES.

Figure 7 - Architecture d’application de gestion (AAG) - Couche 3 de l’AAS du GC.

Figure 8 - Couches internes et mécanismes de communication de l’AAG.

Figure 9 - Autre point de vue de l’AAS du GC.

Figure 10 - Paradoxe de classification des applications classiques.

Figure 11 - Introduction de l’AES dans une application classique.

1.0 - Avant-propos

La Direction du dirigeant principal de l’information (DDPI) du Secrétariat du Conseil du Trésor établit les orientations stratégiques dans le cadre de la mise en œuvre de la Stratégie d’architecture axée sur le service du gouvernement du Canada (SAAS GC). Cette orientation stratégique vise à permettre aux ministères d’adopter une approche commune face aux nouvelles normes et aux nouveaux modèles d’architecture axée sur le service. La SAAS concerne également la conception de programme, la planification stratégique des activités, de même que la conception des systèmes du GC; en effet, il ne s’agit pas uniquement d’une innovation technologique. Il s’agit aussi d’un moyen d’atteindre les objectifs du GC en ce qui a trait à la modernisation des services, la prestation horizontale des services et une meilleure interopérabilité.

Ce document fait partie d’une série consacrée à l’AAS du GC. Ensemble, cette série de documents sur l’AAS du GC présente l’orientation globale de la DDPI, au nom du gouvernement du Canada, pour ce qui est de l’entrée en vigueur de cette notion du service à la clientèle.

2.0 - À propos de ce document

Le gouvernement du Canada procède à l’heure actuelle à des changements et à une - transformation sans précédent. Ce processus de renouvellement dans toute l’administration fédérale a des répercussions à la fois au niveau des secteurs de programmes offerts au public et des services internes. L’administration souhaite tout bonnement mettre encore davantage à contribution la population en général, tout en l’invitant à utiliser les ressources que nous possédons à l’heure actuelle de manière plus efficace, compte tenu des coûts.

En guise d’appui aux objectifs visés, l’architecte en chef et le dirigeant principal de l’information du gouvernement du Canada reconnaissent tous deux l’importance d’une approche globale axée sur les services au moment de mettre en place l’infrastructure de gestion, d’information et de technologie visant à concrétiser la vision d’une administration publique fédérale axée sur le service. Par exemple, Service Canada, récemment inauguré, représente de façon éloquente une telle approche, non seulement en ce qui a trait à la raison sociale, mais aussi à la conception même du service. Ainsi, les services offerts par Service Canada sont le prolongement, à l’intention du public, d’un éventail de services assurés par de nombreux autres ministères fédéraux. Service Canada permet aux citoyens de constater que le gouvernement est en mesure d’offrir un éventail de services intégrés, qui prennent appui les uns sur les autres et ainsi constituent un tout pouvant répondre aux besoins et aux exigences de la population.

L’expression « souci du service à la clientèle » est un paradigme de premier ordre pour rassembler et utiliser des capacités qui relèvent de différentes entités organisationnelles. Dans un environnement axé sur le service, les organisations font en sorte que les ressources soient disponibles pour la collectivité sous forme de services indépendants auxquels on peut avoir accès de façon uniforme. Toutefois, pour concrétiser avec succès la vision axée sur le service, il faut adopter des moyens cohérents de définir et de mettre en œuvre des services à l’échelle de l’administration fédérale. Une façon éprouvée de le faire consiste à élaborer ces services comme s’il s’agissait d’une série d’éléments compatibles que l’on peut facilement combiner et agencer pour atteindre les résultats souhaités, de manière efficace au niveau des coûts, et s’acquitter des nombreux mandats de l’administration publique.

L’expression « Architecture axée sur le service du gouvernement du Canada » (AAS du GC) est celle que privilégie la DDPI pour présenter une série de concepts qui devraient permettre en principe de réaliser les objectifs visés à ce chapitre. Aux yeux de certains groupes cibles, plus particulièrement les lecteurs qui saisissent mieux le volet technique, il pourrait sembler que cette AAS du GC s’apparente à une Architecture axée sur le service typique (AAS comme on dit communément dans la collectivité des technologies de l’information). Même si l’on a effectivement puisé dans les concepts de l’AAS, le SCT estime malgré tout que cette AAS du GC se distingue dans deux secteurs clés : le contexte et l’application.

L’AAS s’impose d’emblée comme pratique exemplaire au niveau de la conception de l’information et de la technologie. Toutefois, l’AAS du GC englobe un ensemble élargi et correspond finalement au résultat de l’élargissement des concepts techniques visant à y intégrer également les secteurs d’activités du gouvernement. Désormais, l’AAS du GC va bien au-delà des domaines technologiques habituels de l’AAS.

En dernier lieu, l’AAS du GC permet une application plus précise et elle offre une orientation et un apport spécifiques, permettant ainsi au gouvernement fédéral canadien d’assurer des services de façon plus harmonieuse, compatible, efficace et efficiente.

2.1 - Objet

Le présent document a pour objectif de présenter un aperçu général de l’AAS du GC de manière à ce que tous les lecteurs aient une vision commune et cohérente du sujet. Après avoir lu ce document, les intervenants auront saisi les grandes lignes de l’AAS et les motifs qui poussent le gouvernement du Canada à adopter cette stratégie, et ils pourront ainsi mieux apprécier l’approche et les couches fonctionnelles de l’AAS du GC qui distinguent cette dernière des modèles typiques d’architecture de réseau.

2.2 - Groupes cibles

Ce document est destiné au grand public et présente un aperçu de haut niveau de l’AAS du GC. Il s’agit d’un document préalable à tous les autres guides et documents de référence portant sur l’Architecture axée sur le service du GC. Ce document n’approfondit pas le volet technique associé à la mise en œuvre de l’AAS du GC, du point de vue des spécialistes. On souhaite principalement que tous les publics aient une meilleure idée générale de ce qui est envisagé concernant l’AAS du GC de même qu’une meilleure compréhension des concepts de base.

De plus, on suppose que la grande majorité auront pris connaissance de l’Énoncé d’orientation du gouvernement du Canada, et c’est précisément pour cette raison que l’on ne revient pas sur les avantages que comporte cette approche, ni sur la raison d’être de l’AAS du GC.

2.3 - Champ d’application

Le présent document consiste en une introduction aux concepts de base du service à la clientèle et fait place à des objectifs précis axés sur le service. Il fait le tour de la question du point de vue du gouvernement fédéral canadien. Il ne vise pas à reprendre des chapitres qui font déjà l’objet de nombreux autres excellents ouvrages sur le sujet. 

3.0 - Aperçu de l'AAS du GC

3.1 - Introduction

L'AAS du GC est l'approche adoptée par la DDPI et elle consiste en un modèle de production global axé sur le service, depuis le niveau administratif, en passant par tous les niveaux d'une organisation, jusqu'aux couches fonctionnelles qui soutiennent les besoins opérationnels.

Le modèle de prestation de services repose sur la théorie du comportement d'un marché. Ainsi, si un service a de la valeur aux yeux d'un client, ce dernier aura tendance à l'utiliser et si un service a beaucoup de valeur, de nombreux consommateurs voudront l'utiliser. C'est ainsi qu'un service peut se transformer en une unité de base réutilisable extrêmement importante dans la planification et la conception des programmes gouvernementaux qui atteignent les objectifs établis et produisent les résultats prévus.

Le marché permet également de constituer une communauté dynamique composée de fournisseurs de services et de consommateurs de services. Règle générale, les entités (soit les gens et les organisations) qui ont les capacités et les habiletés nécessaires appartiennent à la catégorie des fournisseurs de services. Par contre, ceux et celles qui ont des besoins et qui utilisent les services appartiennent à la catégorie des consommateurs de services. Ensemble, ils forment ce que l'on peut parfois appeler la catégorie des participants aux services.

Avec l'échange et la réutilisation des services, les participants devraient (même si cela n'est pas toujours le cas) en retirer certains avantages réciproques. Lors de transactions sans lien de dépendance, les fournisseurs peuvent amortir leurs investissements compte tenu de l'importance de la collectivité visée, tandis que les consommateurs ont facilement accès aux services qu'ils souhaitent sans qu'il soit nécessaire de tout recommencer à zéro. Dans une collectivité fermée comme c'est le cas au gouvernement fédéral, les participants aux services travaillent tous dans le même sens et cherchent à atteindre des objectifs communs, notamment Des résultats pour les Canadiens et les Canadiennes, la prestation horizontale de services, la modernisation des services et une gestion plus efficace des fonds publics. Peu importe le scénario, fournisseurs et consommateurs tirent profit de la présence de l'autre.

Jusqu'à maintenant, l'AAS du GC a surtout mis l'accent sur la réutilisation et l'interopérabilité des services valorisés à l'exécution seulement. Par exemple, le service d'acheminement du courrier, le centre de dépannage informatique ou le système de suivi de la correspondance sont tous des services réutilisables à l'exécution, car avec certains ajustements, ils peuvent sans doute être adaptés aux besoins d'une autre collectivité.

Les phases de planification et de conception sont autant d'occasions pour réutiliser des services. Par exemple, un guide des pratiques exemplaires pour la planification stratégique, un modèle pour les ententes sur les niveaux de service ou un modèle de référence pour la conception de réseaux protégés sont des biens réutilisables de valeur au moment de la planification ou de la conception d'un service. Ces types de services auxiliaires (non opérationnels) ne font pas partie de ceux que l'on utilise dans l'immédiat et se retrouvent donc à l'extérieur du champ d'application initial.

3.2 - Positionner le cadre de fonctionnement

De nombreux ouvrages techniques portent sur l'AAS et différentes organisations ont déjà connu le succès et obtenu des avantages après y avoir eu recours. Il est toutefois de plus en plus évident que pour obtenir une gamme de services réutilisables qui convient parfaitement bien, il faut que ces derniers correspondent au secteur d'activités. Autrement dit, les services doivent être personnalisés et être élaborés en fonction de besoins ou d'exigences précises.

Si l'on refuse de tenir compte de ces impératifs, la réutilisation des services risque d'être fort limitée. Par exemple, advenant que quelqu'un décide d'offrir un service de livraison, ce service pourrait être utilisé également par quelqu'un d'autre qui souhaite faire livrer de la marchandise. Par contre, s'il s'agit au départ de livrer de la crème glacée, par exemple, ce type de service risque fort de ne pas convenir à d'autres. En effet, dans cette hypothèse, les concepteurs auront élaboré un service de livraison par camion réfrigéré, ce qui comporte des frais généraux à la fois élevés et inutiles pour quiconque travaille dans le transport de marchandises sèches. C'est pourquoi il est beaucoup plus facile de prendre les bonnes décisions et de faire les bons choix lorsqu'on tient compte du contexte dans lequel le travail doit se faire et de la façon dont les services seront utilisés.

Le SCT a déjà investi dans un ensemble étoffé de méthodes et de techniques pour l'analyse et l'élaboration des secteurs d'activités gouvernementales dans le cadre d'une approche commune. Le modèle de référence stratégique du gouvernement du Canada (MRSGC) met de l'avant un langage commun utilisé pour définir les activités du secteur public du Canada selon différentes perspectives, pour que les ministères, les groupes de ministères et les organismes centraux puissent à leur tour définir leurs propres exigences plus clairement, de même que les services communs et les processus administratifs susceptibles de répondre à leurs besoins. Ce MRSGC est la première étape vers un degré d'interopérabilité et un niveau de réutilisation des services plus élevés. Grâce à une conception en commun des services, le tout dans l'intention d'en faire des services réutilisables, il est possible de retirer des avantages considérables du service à la clientèle. Le MRSGC correspond à la norme en vigueur dans toute l'administration publique qui sert de balise à l'élaboration des services administratifs et à la création d'un registre des dossiers utilisé pour le catalogage des services aussi bien que pour l'examen des activités fonctionnelles stratégiques.

Le MRSGC regroupe dix-neuf types de services fonctionnels différents utilisés pour classer par catégories les nombreux services offerts par les différents ministères et organismes gouvernementaux. Ces types de services servent au départ à faire la distinction entre les services administratifs et les services techniques. En guise de comparaison, pensez à vos cours de physique du secondaire, où vous avez appris qu'il n'y a au total que six (6) « machines simples » (levier, treuil, plan incliné, coin, poulie et vis). Tout le reste, qu'il s'agisse d'une simple agrafeuse ou brocheuse, ou d'une navette spatiale, sont le résultat de la réutilisation et de l'intégration de ces six (6) machines simples.

Les dix-neuf types de services associés au MRSGC sont les unités fonctionnelles de base avec lesquelles on s'emploie à atteindre les résultats souhaités dans le cadre des nombreux programmes offerts par le gouvernement fédéral. Différents services peuvent être combinés pour constituer des services de niveau plus élevé répertoriés à l'aide de modèles baptisés MISR (Modèles d'intégration des services et de responsabilisation). Ces modèles peuvent servir à faire connaître le rapport de responsabilisation qui existe entre les différents fournisseurs de services et les consommateurs, dans le cadre du processus de négociation des services.

Le MRSGC présente également des configurations de processus génériques pour chaque type de service fonctionnel. Cela permet de déterminer et de normaliser les services à un niveau plus modulaire. En puisant à même ces configurations génériques, les différents ministères sont en mesure de déterminer lesquelles peuvent être personnalisées et réutilisées de façon plus pointue. Par exemple, chacune des configurations comporte une fonction baptisée « perçoit et  comptabilise les droits et frais payables [nom du service] ». Grâce à l'Internet, et à la présence de plus en plus marquée du GED, de nombreux ministères ont décidé d'utiliser davantage cette fonction, à l'aide d'une carte de crédit. Un nouveau service a donc vu le jour, soit le BARG (Bouton d'achat du receveur général). En fixant son choix sur un processus commun, puis en le transformant en véritable service partagé, TPSGC a réussi à mettre en place une approche commune pour l'élaboration d'un mode de perception des droits et des frais en ligne, au moyen d'une carte de crédit, sans qu'il soit nécessaire de demander à chacun des ministères de réinventer la roue.

L'AAS du GC est une architecture en couches, et à ce titre, elle fait appel aux mêmes principes, afin de combiner et de réutiliser des services, de manière à en créer d'autres, plus puissants et plus avantageux, des services de plus en plus évolués. C'est cette réalité toute simple qui fait ressortir l'importance du service à la clientèle.

Lorsqu'un processus se transforme en service, cela fait habituellement boule de neige, c'est-à-dire, qu'un service en entraîne un autre. Par exemple, le BARG devait également permettre aux ministères de vérifier les transactions par carte de crédit, d'offrir un remboursement ou peut-être même d'apporter d'autres correctifs, le cas échéant. La réalité est telle que le BARG s'est transformé en application assortie d'une multitude de fonctionnalités visant à soutenir et à administrer un service partagé.

L'AAS du GC a donc comme point de départ le MRSGC, en tant qu'approche commune pour définir les programmes gouvernementaux et les décomposer en services et en processus administratifs. De là, ne reste plus qu'à contextualiser la création de solutions automatisées pour soutenir les différents secteurs d'activités. Car tout compte fait, le développement d'une application n'a rien à voir avec la création d'un code, et doit servir uniquement à répondre à des exigences bien précises.

Figure 1 - Lien entre l'AAS du GC et le MRSGC

Ainsi, les services et les processus élaborés à partir du MRSGC sont souvent reliés à la mise en œuvre d'applications de gestion (la couche supérieure de l'AAS du GC). Ces applications de même que les nombreuses composantes subordonnées (de l'AES et de l'ACT) deviennent elles-mêmes des ressources associées au MRSGC et elles contribuent au soutien des besoins en gestion.

Sur la planète des technologies de l'information (TI), ce sont les applications informatiques que l'on développe ou que l'on acquiert qui répondent aux impératifs du service. En adaptant adéquatement les applications aux besoins du service, la souplesse et la faculté d'adaptation d'une organisation progressent de manière significative. De toute évidence, si l'on effectue une application individualisée pour une fonction de gestion quelconque, tout changement ou abandon de conditions aurait un effet sur cette seule application sous-jacente et probablement pas sur une série d'autres applications. À l'inverse, si une application concerne une multitude de fonctions de gestion, toute modification apportée à l'une ou l'autre fonction a un impact sur cette application.

3.3 - Calculer la valeur de l'AAS du GC

Comme on l'a montré précédemment, il y a des avantages significatifs à pouvoir décortiquer une machine complexe en une série de machines plus simples. Dans le monde des TI, des systèmes complexes peuvent être présentés sous forme de plus petites unités discrètes appelées composantes. Lorsque le souci du service à la clientèle est associé à une application, nous augmentons la tolérance au changement de cette dernière et faisons en sorte que les composantes individuelles soient réutilisables. Ce processus de décomposition se répète ce qui permet de constituer plusieurs couches. L'idée maîtresse est de chercher à gérer le processus global, avec une approche claire pour réussir la décomposition de l'application de façon systématique, et un ensemble d'idées simples qui sert de point de départ logique à la réorganisation des nombreux éléments en couches distinctes. Nous sommes au cœur de l'architecture de référence de l'AAS du GC.

En mettant de l'avant ces couches de manière officielle, l'industrie reconnaît que la valeur intrinsèque du service à la clientèle demeure sa capacité : 

• de faciliter la croissance pratique et réalisable de systèmes de gestion à grande échelle;
• de fournir un paradigme simple à la carte permettant d'organiser de grands réseaux de systèmes qui doivent fonctionner ensemble (soit le principe de l'interopérabilité);
• de minimiser les hypothèses ou présomptions au niveau de la confiance, chez les fournisseurs et les consommateurs, de manière à favoriser une plus grande souplesse et un plus haut degré d'autonomie;
• d'intégrer l'ensemble des fonctionnalités, au-delà des velléités de propriété ou d'appartenance.
  

La clé du succès, pour que ces avantages se concrétisent, est de poursuivre sur cette lancée et de favoriser la création et la réutilisation de services. Une bonne dose de collaboration est nécessaire si l'on souhaite que les fournisseurs développent et enregistrent un portefeuille de services réutilisables, à la portée de nombreux consommateurs potentiels. Voici comment l'on pourrait représenter ce modèle de collaboration.

Figure 2 - Processus de négociation du service

4.0 - Les trois couches de l'AAS du GC

L'AAS du GC est composée de trois couches distinctes dans un contexte de conception de programmes/activités (soit la quatrième couche virtuelle). Ces trois couches correspondent à une approche dûment reconnue dans l'industrie, en ce qui a trait à la structuration en couches de toute architecture des TI. La grande différence réside dans le fait qu'on a choisi l'encapsulation et le nommage des couches pour que le nom attribué à chacune corresponde exactement à ce qu'elle offre et représente, et soit le reflet fidèle des motifs qui nous ont poussés à agir de la sorte.

Figure 3 - Les trois couches de l'AAS du GC

4.1 - Les avantages d'une structuration en couches

L'AAS du GC est structurée en couches pour les raisons bien connues énumérées ci-dessous.

• Il est plus facile d'examiner une couche à la fois, en l'envisageant comme un tout, plutôt que d'essayer de comprendre l'architecture au complet, de haut en bas.
• Le lien de dépendance entre les couches est réduit au minimum et les interconnexions entre entités sont présentées sous forme d'un système administrable.
• D'ordinaire, les normes sont intégrées aux interfaces des couches pour qu'un nombre maximum de consommateurs puissent utiliser les services offerts. Le modèle de référence d'interconnexion de systèmes ouverts est souvent cité en exemple.
• À mesure que l'on passe à travers les différentes couches (ou pyramide, si vous préférez), le niveau d'abstraction augmente, les détails et le niveau de complexité s'estompent, ouvrant la voie à la conceptualisation et à la résolution de problèmes de plus haut niveau.
• Une fois les normes bien établies, les couches peuvent être remplacées l'une par l'autre, en collaboration avec d'autres fournisseurs. Par exemple, dans le modèle de référence OSI, il existe une multitude de protocoles de communication TCP/IP parmi lesquels faire un choix.

En dernier lieu, comme c'est le cas pour n'importe quel immeuble, dès qu'un étage est construit, il est normalement plus facile d'y ajouter un autre étage (si cela a du sens, bien entendu).

4.2 - Les différentes couches

On a longuement réfléchi à la question suivante : « Pourquoi faut-il trois couches pour définir l'AAS du GC »? La réponse est multiple, à savoir : 

• Chaque couche assure les services requis par rapport à la couche au-dessus
• Chaque couche se définit par elle-même
• Chaque couche donne corps à un concept architectural ou technologique en particulier

L'AAS du GC comporte donc les trois couches suivantes : 

Couche 1 -  - Architecture à composantes technologiques

Couche 2 -  - Architecture d'échange de services

Couche 3 -  - Architecture d'application de gestion

Chaque couche fera maintenant l'objet d'une discussion.

4.2.1 - Architecture à composantes technologiques - Couche 1

Figure 4 - Architecture à composantes technologiques (ACT) - Couche 1 de l'AAS du GC

L'architecture à composantes technologiques (ACT) englobe des produits et des services, de même que les architectures de soutien respectives, propres à un fournisseur et elle fournit la liste des composantes de plus bas niveau (soit les composantes primaires) pouvant être réutilisées telles quelles dans toute l'administration fédérale. Autrement dit, vous pouvez vous en servir  sans les modifier. Toutefois, il ne s'agit pas d'une utilisation partielle, et il n'est pas question non plus d'en modifier le comportement choisi. À priori, il s'agit donc d'une boîte noire qui fait ce qu'elle doit faire. Cette couche renferme tout le matériel et les logiciels nécessaires à la présentation des composantes des modules (sans égard à la complexité et à la taille) que les fournisseurs ont à offrir. En voice des exemples : le langage Java ou une carte vidéo. Elles sont ce qu'elles sont, ni plus, ni moins. Vous les utilisez telles quelles, et n'avez pas vraiment la possibilité de les modifier, sans demander au préalable l'autorisation du fournisseur. Il s'agit de produits indépendants et sans interaction entre eux. La notion d'interopérabilité au niveau de cette couche n'est pas obligatoire étant donné que chaque fournisseur a le droit d'utiliser des normes appropriées à sa mise en service. Cela ne signifie pas toutefois que les fournisseurs ne pourraient pas et ne devraient pas essayer d'interopérer directement entre eux, et le fait est que certains y parviennent; toutefois, il ne s'agit pas d'une exigence du gouvernement du Canada.

Un des éléments importants au niveau de cette couche est la granularité. Autrement dit, il s'agit de la taille élémentaire des ensembles de données mis au point par le vendeur/fournisseur. Plus le degré de granularité est élevé, plus il y a de possibilités de personnaliser un système, car le nombre d'éléments (objets, informations ou données) parmi lesquels choisir est plus élevé.

Les applications classiques autonomes incorporées directement dans les plateformes des fournisseurs font également partie de l'ACT. Ces applications maison sont sur un pied d'égalité avec les produits du fournisseur car tout ce qui les différencie, finalement, c'est celui ou celle qui est responsable du développement. Bien entendu, les produits d'infrastructure offerts par les fournisseurs s'intègrent normalement plus facilement dans le modèle axé sur le service, mais grâce aux adaptateurs et aux techniques de codage personnalisé disponibles de nos jours, ces applications ne sont pas en reste.

4.2.2  - Architecture d'échange de services - Couche 2

Figure 5 - Architecture d'échange de services (AES)  -  Couche 2 de l'AAS du GC

L'architecture d'échange de services (AES) est la couche intermédiaire qui appuie l'application personnalisée d'un élément de la couche 1 (ACT) à ce que l'on pourrait appeler un service d'infrastructure ou i-service. Par exemple, la gestion des tâches et l'établissement du calendrier sont des éléments du courrier électronique que l'on peut représenter, traiter et utiliser séparément. Habituellement, ce que l'on constate, c'est qu'un modèle de service normalisé est mis de l'avant de manière à « emballer » un service propre à un fournisseur pour le rendre conforme aux normes du GC. Ces services d'infrastructure serviraient alors de bloc fonctionnel sur lequel d'autres services thématiques à valeur ajoutée (p. ex. des services de voyages ou de santé) viendraient se greffer.

Les services administratifs automatisés, connus également sous le nom de services mixtes dans le jargon de l'industrie des TI, sont des services intégrés à d'autres services et ils représentent le volet clé à valeur ajoutée de l'AES. Règle générale, les services mixtes permettent d'exécuter des fonctions ou des processus de gestion clés qui font partie d'une application plus évoluée ou d'un mécanisme de prestation des programmes. Le consommateur typique de ce type de service plus évolué peut être d'autres services internes, des applications ou des services externes à l'intention des citoyens ou des entreprises. 

Peu importe l'utilisation, la nature récurrente des services, c.-à-d. lorsqu'ils peuvent s'appeler eux-mêmes, ouvre la porte à la complexité des programmes, lorsque nécessaire, ou à la simplicité, lorsque souhaitable. La Figure 5 a été réduite à sa plus simple expression : on y voit une seule et unique couche mixte faisant référence aux services administratifs automatisés, quoique un service mixte puisse parfois en englober d'autres, de manière plus ou moins approfondie.

Fait important à signaler, pour cette couche, on y fait la distinction entre les services offerts par le biais d'interfaces exclusives ou d'application industrielle et les services offerts par le biais d'interfaces approuvées dans toute l'administration fédérale. Au nombre des interfaces de l'industrie, mentionnons le langage ebXML, les services Web et l'IAE traditionnelle (Intégration d'application d'entreprise). Un exemple d'interface approuvée à l'échelle de l'administration fédérale pourrait être le langage XML utilisé par le courtier de services de la Voie de communication protégée. Lorsqu'il est inutile d'adapter une norme de l'industrie, la norme approuvée par le GC pourrait bien être la même. Un bon exemple est le fait que le GC a choisi d'adopter l'interface POP3 pour que la clientèle puisse communiquer par courriel avec les nombreux serveurs du GC.

La Figure 6 - Anneau des services communs de l'ACT vers l'AES illustre des fournisseurs qui présentent une interface en tant que composante de l'ACT. Même si de nombreux fournisseurs ont de plus en plus tendance à s'éloigner des interfaces exclusives, ce qui est déjà en soi une bonne nouvelle, pour être considérée comme étant un i-service dans l'AES, toute fonctionnalité composante de l'ACT doit être offerte par le biais d'une interface approuvée à l'échelle du GC.

Dans la couche AES, l'AAS du GC peut simplement intégrer les interfaces de l'industrie suffisamment larges pour permettre à tous les ministères de bénéficier de l'interopérabilité au moment de choisir les services dont ils ont besoin auprès des fournisseurs et des sources. Dans d'autres cas, les composantes et les interfaces de l'AAS du GC seront plutôt « mises en forme » à l'aide de normes définies à l'interne et à la grandeur du GC. Cela aura pour effet d'isoler les ministères des véritables fournisseurs de services au niveau de l'ACT et de rehausser le degré d'autonomie du fournisseur.

Lorsqu'une telle mise en forme se produit, l'en-tête de message (en tant que partie intégrante de l'intervention sur machine) pourrait être potentiellement considéré au même titre que le contenu du message (appelé aussi charge utile). Dans certains cas, l'emballage ou la mise en forme ne servira qu'à isoler l'en-tête. Dans d'autres cas, l'interface visera également la charge utile.

Figure 6 - Anneau des services communs de l'ACT vers l'AES

4.2.3 - Architecture d'application de gestion - Couche 3

Figure 7 - Architecture d'application de gestion (AAG) - Couche 3 de l'AAS du GC

L'architecture d'application de gestion (AAG) est au sommet de la pyramide. Fondamentalement, elle permet aux entrepreneurs de rassembler un ensemble de services du GC (ou non) dans le cadre d'une nouvelle proposition sur la valeur. Règle générale, la portée d'une application est assez large et cette dernière peut être développée de manière à englober un peu plus ou un peu moins de fonctionnalités, selon le temps qu'on a et les ressources disponibles. Des applications peuvent être créées par le biais d'un nouveau code, d'un code acquis ou d'un code existant recyclé. Par exemple, en reciblant des services ministériels et pangouvernementaux existants en matière de santé, on pourrait créer un service consultatif mixte en matière de santé et de voyage en temps réel et universel, y compris les rappels d'aliments, les avis sur la qualité de l'air et les renseignements médicaux à l'intention des voyageurs, le tout dans un guichet unique. Des services publics d'une telle ampleur auraient certainement des répercussions positives sur les services existants ou les nouveaux services envisagés dans les secteurs public et privé, selon les niveaux de service et les contrôles d'accès qui y sont associés.

En raison de leur nature même, les applications de l'AAG ne peuvent être « directement » réutilisées. Les utilisateurs de ces applications sont, en règle générale, des gens qui laissent entendre que l'AAG renferme les éléments qui permettent la prestation de services. Pour soutenir l'interopérabilité entre les applications de cette couche, ces dernières doivent faire appel aux services réunis dans l'Architecture d'échange de services (AES) où l'échange de renseignements est possible. Autrement dit, l'AAG correspond à la couche présentation, au même titre que toute logique d'interaction associée et autres aspects non réutilisables d'une application de gestion.

L'AAG est également décomposée en couches distinctes. Ces couches sont connectées par le biais d'un bus des services d'application (BSA), qui peut être exclusif et/ou local à l'application. Lorsqu'une interaction avec l'AES entre en ligne de compte, une interface des services intégrés (ISI) fournit le modèle normalisé nécessaire pour assurer les services externes.

Pour s'assurer que les composantes de niveau inférieur seront aussi réutilisables que possible, l'AAG conserve dans ses couches internes fonctionnelle et persistance les paramètres et les données spécifiques de ce secteur d'activités. Lorsqu'une fonction de la couche fonctionnelle devient une fonctionnalité commune à plusieurs secteurs d'activités, on peut alors envisager la faire passer vers l'AES et l'offrir à titre de nouveau service.   

Figure 8 - Couches internes et mécanismes de communication de l'AAG

Voici un bref aperçu des couches internes de l'AAG.

Couche présentation - Affichage du contenu, des messages-guides et des résultats dans l'appareil utilisé (p. ex. navigateur, cellulaire, PDA, écran 3270, etc.), y compris les fonctions de transformation pour appuyer les technologies d'accessibilité.

Couche interaction  - Concerne l'aide fournie à l'utilisateur final et la gestion de la saisie de données, des processus, et de l'interopérabilité entre les services (fonction de retour, fonction d'aide, menu des changements, etc.).

Couche fonctionnelle  Gestion de la logique d'ensemble et de la marche du travail d'une session. Englobe les modèles des processus de gestion qui permettent aux consommateurs et aux fournisseurs d'avoir une idée commune de chaque processus et de sélectionner des processus et des services en fonction des réponses fournies par le partenaire.

Couche objet - - Pour s'occuper de paramètres spécifiques à l'AAG, notamment la validation de données. Englobe des éléments conçus en conformité avec les normes du COI (p. ex. des entités définies selon les spécifications et les lignes directrices du UN\CEFACT - une application ISO 11179).

Couche persistance - Recherche et stockage d'informations pour assurer la continuité de la session, y compris des technologies telles une signature numérique et  le chiffrement, pour protéger l'intégrité des objets et des opérations électroniques entre participants, et conseils sur la façon de les sauvegarder.

L'AAG réunit un éventail d'applications, entre les applications spécialisées et les applications multifonctionnelles ou à usages multiples. L'AAG renferme également des applications uniques dans son sens le plus restreint, c.-à-d. qui concernent un seul secteur d'activités, un seul programme et même un seul ministère. Autrefois, à défaut d'un véritable service à la clientèle et en l'absence de normes bien définies, on avait tendance à privilégier des applications de plus en plus vastes, qui englobaient un large éventail de besoins du service. Ainsi, on s'assurait que tous les volets d'une solution envisagée pourraient interagir entre eux et former un tout.

L'AAS du GC aura pour résultat de favoriser l'émergence de plus petites applications, elles-mêmes mieux ciblées, dès que tous et chacun auront compris que projet (ou programme) et application ne font qu'un. Par exemple, dans la figure ci-dessus, il pourrait s'agir d'un projet consultatif en matière de santé et de voyage dont la principale réalisation se résumerait à l'application comme telle. Mais dans un monde où il est question de service à la clientèle, l'application sera plutôt synonyme de portefeuille ou série de composantes associées à la santé et au voyage, rassemblées dans un but bien précis, soit d'offrir un service de consultation global. Dans l'éventualité où les services sont réutilisés (ou modifiés), les applications de haut niveau pourront alors être recentrées.

Une grande partie de l'AAG est axée sur le temps consacré au développement de l'application, étant donné que les modèles et les schémas applicables peuvent être partagés et réutilisés par de nombreuses autres applications pendant la phase de développement. Ces modèles et ces schémas feront l'objet de discussions dans les documents à venir.

4.3 - Autre point de vue sur les trois (3) couches

L'AAS du GC peut être envisagée d'un autre point de vue, à l'intention de ceux et celles qui sont toujours un peu perplexes à ce sujet.

Figure 9 - Autre façon de voir l'AAS du GC

Même si la Figure 9 est plutôt schématique, cela ne signifie pas pour autant que l'ensemble de la conception et du développement se situe dans la couche supérieure. La conception des services se fait toujours dans la couche 2, mais on se consacre principalement, il est vrai, au temps d'exécution.

5.0 - - Transition vers l’AAS

L’objectif premier du service à la clientèle est de s’éloigner des vastes applications monolithiques, celles qui traditionnellement n’ont pas de composantes bien définies accessibles indépendamment de l’application dans laquelle elles sont intégrées. La Figure 10 ci-dessous illustre justement ce type d’application fermée.

Figure 10 - Paradoxe de la classification des applications classiques

Vous remarquerez que l’application chevauche deux couches, l’AAG et l’ACT. Il n’y a pas de contre-indication étant donné que l’application comporte des aspects qui se retrouvent dans les deux couches. Normalement, la seule façon d’utiliser l’interface d’une telle application (sans faire de changements) est d’imposer une logique quelconque à son interface d’utilisateur existante (p. ex. une macro clavier ou un grattage écran).

On cherche plutôt à développer des applications en puisant à même les composantes des couches de l’AAG, en utilisant le plus de composantes possible provenant de la « boîte noire » de l’ACT, et en y ayant toujours accès par le biais d’une AES officielle.  

Figure 11  - Introduction de l’AES dans une application classique

Les applications doivent donc être développées ou modifiées de façon à ce que les éléments de logique réutilisable soient accessibles par le biais de l’AES. Dans l’exemple donné, l’application exécute toujours toutes ses fonctions originales, mais certaines composantes utiles ont été isolées et offertes pour utilisation externe par le biais de nouvelles interfaces AES. Ainsi, deux nouvelles applications peuvent tirer profit d’avantages reconnus autrefois réservés à cette application classique. On vise donc à déplacer le plus possible de cette nouvelle logique à travers les différentes couches, vers l’ACT. De cette façon, on aura accès à un nombre de plus en plus élevé de « boîtes noires » réutilisables, avec de plus en plus de fonctionnalités sur lesquelles de nouvelles infrastructures pourront être mises en place, à l’intérieur comme à l’extérieur de l’organisation.

6.0 - Étapes suivantes

Après avoir lu ce guide d’introduction, le lecteur est invité à approfondir les domaines ou les sujets qui l’intéressent plus particulièrement.

Les cadres, les planificateurs des opérations, les analystes de programmes et autres membres du personnel non technique voudront sans doute jeter un coup d’œil au Guide d’introduction - Cadre de fonctionnement/conception de l’AAS du GC pour des conseils spécifiques sur l’entrée en vigueur de l’AAS du GC dans le domaine de la gestion.

Les techniciens seront sans doute plus intéressés par le document intitulé Modèle de l’AAS du GC où ils trouveront de l’information détaillée sur le modèle de référence de l’AAS du GC, comme point de départ au développement d’applications et de composantes.

Les Principes déterminants de l’AAS du GC offre une orientation de haut niveau pour la mise en place de l’AAS du GC et apporte un complément d’information. Ces principes s’appliquent aux couches administratives et aux couches technologiques de l’architecture.

7.0 - Annexes

7.1 - Acronymes et abréviations