Développer, Employer, at Maintenir Une Architecture STI pour Votre Région

[ Précédente : Chapitre 6 ]

[ Suivante : Chapitre 8 ]

---

CHAPTER 7 - UTILISATION D’UNE ARCHITECTURE RÉGIONALE DES STI

TABLE DES MATIÈRES

7.1 Utilisation dans une planification du transport

7.2 Utilisation dans une programmation, l’établissement d’un budget ou une planification des immobilisations

7.3 Utilisation dans la mise en oeuvre des projets

L’architecture régionale des systèmes de transport intelligents (STI) a été élaborée dans les quatre sections précédentes. Maintenant que vous avez en main votre architecture régionale des STI, il vous faut l’utiliser. La présente section vous décrit comment le faire.

Dans les sections précédentes, à mesure que l’élaboration de l’architecture régionale des STI prenait forme, le processus de planification du transport et les documents connexes ont été des intrants majeurs à chacune des étapes du processus d’élaboration de l’architecture. Les sections 7.1 et 7.2 portent sur des façons dont les planificateurs du transport peuvent utiliser l’architecture régionale des STI en tant que partie intégrante du processus de planification du transport. La section 7.3 montre aux concepteurs et aux ingénieurs d’application du transport des façons dont l’architecture régionale des STI peut être utilisée pour soutenir la mise en oeuvre de projets qui contiennent des composants STI.

Étape 5: Utilisation d’une architecture régionale des STI

• Utiliser l’architecture dans une planification du transport
• Utiliser l’architecture dans une programmation, l’établissement d’un budget ou une planification des immobilisations
• Utiliser l’architecture dans la mise en oeuvre des projets

Objectifs

• Incorporer pleinement les composants STI aux processus de planification et de la programmation des transports dans la région
• Soutenir la définition des projets de STI qui tiennent compte totalement des possibilités d’intégration établies dans l’architecture régionale des STI

Processus - Principales activités

Processus de soutien au transport

• Planification à long terme : Une architecture régionale des STI peut soutenir toutes ces tâches en encourageant les intervenants à participer, de même que l’intégration des systèmes et des ressorts territoriaux
• Planification stratégique des STI : Les extrants d’une architecture régionale des STI peuvent servir de base pour les plans et les tâches additionnelles requises pour définir des questions comme le financement, la gestion des systèmes et l’exploitation, les choix technologiques régionaux, etc.
• Autres activités de planification : Une architecture régionale des STI peut soutenir des activités de planification, comme la planification de la gestion de la circulation de la sécurité, du fret, de l’exploitation, etc.

Programmes de soutien et établissement de budgets

• Planification des immobilisations et établissement de budgets : Les projets d’une architecture régionale qui requièrent des fonds en fiducie doivent être incorporés aux processus de planification des immobilisations et d’établissement des budgets

Soutien à la mise en oeuvre des projets

• Mise en oeuvre des projets : Une architecture régionale des STI peut soutenir les principales activités d’analyse de l’ingénierie des systèmes

Intrants - Sources d'information

• Architecture régionale des STI
• Architectures de projets ou plans de projets de STI

Extrant - Résultats du processus

• Planification de produits qui incorporent pleinement les composants STI aux plans, aux programmes et aux budgets régionaux, provinciaux et institutionnels
• Programmation de documents et de plans d’immobilisations qui établissent des séquences efficientes reflétant les recommandations relatives à l’interdépendance et au séquençage des projets de STI
• Mise en oeuvre de projets à partir de l’architecture régionale des STI qui tient compte des possibilités d’intégration dans l’architecture

La Figure 18 montre comment la présente section est organisée. Des processus de planification sont utilisés pour déterminer les projets dont la mise en oeuvre permettra de répondre aux besoins régionaux. Une fois financés, les projets sont mis en oeuvre. L’architecture régionale des STI soutient les trois étapes décrites à la section, soit la planification, la programmation et la mise en oeuvre.

L’utilisation de l’architecture tout au long du cycle de vie des projets représente à la fois un avantage et un défi. Elle est avantageuse, puisque l’architecture améliore, à chaque étape, la continuité entre le processus de planification du transport et la mise en oeuvre ultérieure des projets. L’architecture régionale est aussi confrontée au défi d’alimenter les trois étapes, de même que leurs perspectives et leurs besoins variés. En fait, la difficulté consiste à créer une architecture régionale des STI, les processus et les documents d’appui à un niveau suffisamment élevé pour pouvoir soutenir la planification à long terme, d’une part, et suffisamment détaillé pour pouvoir fournir une orientation aux responsables de la mise en oeuvre des projets, d’autre part. La section 7 fournit la meilleure information disponible et une orientation qui vous permettront de surmonter cette difficulté et d’utiliser l’architecture de manière productive dans votre région.

7.1 Utilisation dans une planification du transport

Cette section oriente l’utilisation d’une architecture régionale des STI dans la planification du transport. En raison des variantes régionales et locales dans la planification du transport, cette orientation offre un vaste éventail de possibilités disponibles à chaque province, région ou organisme plutôt qu’une seule recommandation. Fondamentalement, il n’est pas nécessaire de modifier les processus de planification mis en place dans la région aux fins de l’utilisation de l’architecture régionale des STI. L’architecture est un outil qui peut servir à soutenir la planification des STI dans le contexte des processus existants de planification du transport. Les intervenants locaux doivent déterminer la meilleure façon d’incorporer l’architecture régionale des STI et les produits qui résultent de son élaboration dans le processus de planification du transport.

Le but d’un processus de planification est de prendre des décisions éclairées relativement à l’investissement de fonds publics dans des systèmes et des services de transport régional. L’utilisation de l’architecture régionale des STI pour soutenir les activités de planification constitue une étape importante dans l’intégration des STI au processus traditionnel de prise de décisions des planificateurs et des autres professionnels du transport. Comme l’ont montré les étapes précédentes du processus d’élaboration de l’architecture régionale des STI, les plans et les programmes de transport sont des intrants cruciaux d’une telle élaboration. Une fois achevée, une architecture peut fournir au processus de planification des renseignements détaillés et particuliers aux STI.

La Figure 19 19 montre certaines étapes du processus de planification du transport. Ces étapes seront élaborées dans les sections suivantes. Le processus s’inspire d’une vision régionale et d’un ensemble de buts qui orientent les stratégies du transport qui visent à apporter des améliorations aux immobilisations et à l’exploitation. Les organisations de planification évaluent et priorisent les diverses stratégies, et l’extrant qui en résulte est un document appelé « plan de transport à long terme » (ou parfois « plan de transport » ou « plan de transport régional »). Ce plan est un extrant aux fins d’une planification à long terme. Une fois programmé, un projet peut commencer (voir la section 7.3). Toutes ces étapes surviennent parallèlement à des facteurs critiques et à des intrants présentés dans la Figure 19. Une architecture régionale des STI peut soutenir chacune des étapes du processus. Le soutien aux étapes de la planification à long terme est présenté à la section 7.1.1. En plus du document de planification à long terme, des documents de planification particuliers aux STI sont créés, comme un plan stratégique des STI. Ces plans et leur lien avec l’architecture régionale des STI sont présentés à la section 7.1.2. Finalement, la section 7.1.3 aborde d’autres activités de planification, comme la planification du fret ou la planification opérationnelle.

7.1.1 Planification à long terme

Dans le processus de planification du transport traditionnel, le plan à long terme est l’extrant du processus de planification à long terme. À travers le Canada, ce plan est appelé « plan de transport régional » (PTR), « plan de transport à long terme » (PTLT) ou tout simplement « plan à long terme » (PLT). Dans le présent document, le plan est appelé « plan à long terme », « le plan » ou « PLT ». Il documente l’orientation des politiques dans la région et décrit comment les projets et les programmes de transport qui seront mis en oeuvre sur une période de 20 ans ou plus. Le plan doit être mis à jour périodiquement par chaque province ou zone métropolitaine. L’architecture régionale des STI peut servir d’intrant direct au plan. Dans certains cas, elle peut être incorporée au plan lui-même. Comme l’indique la Figure 19, diverses activités de planification peuvent mener à la publication du plan que l’architecture peut aussi soutenir.

Le plan à long terme reflète l’approche à long terme utilisée par une province ou une région métropolitaine pour construire, exploiter et entretenir un système de transport intermodal. Il est un forum sur les politiques concernant l’équilibre des investissements en transport entre les modes, les zones géographiques et les institutions. Une architecture régionale des STI est liée à la fois au plan provincial de transport, au plan de transport de la région métropolitaine et aux plans de transport à long terme des organismes. Comment une architecture régionale des STI peut-elle soutenir le processus de planification du transport?

Comment une architecture régionale des STI peut-elle soutenir le processus de planification du transport?

• Les services décrits dans l’architecture régionale des STI peuvent servir de fondement aux stratégies d’exploitation qui peuvent être utilisées pour améliorer le système de transport et, ainsi, atteindre la vision et les buts de la région.
• L’architecture régionale des STI peut aussi servir à soutenir l’évaluation et l’ordre de priorité des stratégies de deux façons : 1) par le truchement de la définition (contenue dans l’architecture) des systèmes de collecte et d’archivage des données qui soutiennent la collecte des données requises pour l’évaluation et 2) par le truchement d’information détaillée sur les projets de STI et leur séquençage qui peut être utilisée pour soutenir la priorisation.
• La définition d’un système de transport intégré décrit par l’architecture régionale des STI peut soutenir un élément clé du plan de transport, par exemple « l’exploitation et la gestion du système de transport ».
• Le processus d’élaboration et d’entretien d’une architecture régionale des STI peut contribuer à améliorer le lien entre l’exploitation et la planification grâce à la participation plus active d’un plus grand bassin d’intervenants de ces deux secteurs du transport.

Une des premières étapes dans l’utilisation d’une architecture régionale des STI pour soutenir la planification du transport consiste à déterminer la ou les architectures régionales des STI qui s’appliquent au domaine de planification. Dans la plupart des cas, il y a une seule architecture qui correspond au domaine provincial ou métropolitain de planification, et le choix est évident. Dans quelques régions du pays, plus d’une architecture régionale des STI peut s’appliquer. Si c’est le cas dans votre région, il est important de comprendre la relation entre chaque architecture et le processus de planification du transport, puis de documenter cette compréhension de la manière dont chaque architecture sera utilisée. Il est aussi crucial de coordonner les architectures susceptibles de se chevaucher afin de minimiser la redondance et de s’assurer qu’elles sont cohérentes. (Voir la section 3.2 pour obtenir plus d’information sur la définition de la portée d’une architecture régionale des STI.)

Stratégies opérationnelles

Le processus de planification commence habituellement par une vision régionale et des buts. Ces buts sont souvent des énoncés de niveau élevé, comme « préserver le système de transport » ou « améliorer la sécurité publique ». Ces buts de niveau élevé sont ensuite définis sous la forme d’objectifs, de politiques ou de stratégies. Comme l’indique la Figure 19, les stratégies sont surtout des améliorations apportées aux immobilisations ou à l’exploitation. L’architecture régionale des STI peut fournir un éventail d’améliorations qui peuvent être apportées à l’exploitation au moyen des services qui y sont définis.

À titre d’exemple, la stratégie suivante, qui soutient le but de la préservation du système de transport, pourrait s’appliquer :

Utiliser la technologie, des techniques innovatrices et de nouveaux matériaux pour améliorer le cycle de vie du système de transport, fournir des chantiers plus sécuritaires, accroître la productivité et fournir en temps réel des renseignements sur la construction et l’entretien, y compris les retards prévus, pour permettre aux voyageurs de planifier leurs déplacements et d’éviter les chantiers routiers.

Cette stratégie emprunte divers services contenus dans une architecture provinciale des STI typique, y compris la gestion des chantiers routiers, la diffusion des renseignements sur la circulation et des renseignements aux voyageurs. D’autres plans de transport à long terme fournissent des exemples additionnels de stratégies qui puisent leur origine dans une architecture régionale des STI. Il s’agit d’une façon d’utiliser une architecture régionale des STI dans le processus de planification.

Les stratégies dont la principale solution réside dans des projets de transport traditionnel pourraient ajouter des composants ou des services STI à leur solution. Par exemple, s’il prévoit l’élargissement d’un corridor pour réduire la congestion, un projet pourrait inclure l’incorporation de composants ou de services STI afin de gérer le corridor amélioré.

Évaluation et ordre de priorité des stratégies

Les planificateurs du transport utilisent une variété d’outils pour évaluer et prioriser les stratégies visant à améliorer le transport. Le concept de mesure du rendement, qui met l’accent sur le rendement en matière d’exploitation du système de transport, est au coeur de cette évaluation. L’architecture régionale des STI et, dans une certaine mesure, le plan stratégique des STI décrit plus bas, peuvent fournir des mesures du rendement des capacités d’exploitation et de gestion fournis par les services STI. Les mesures du rendement et la collecte des données définies dans l’architecture régionale des STI peuvent fournir un accès aux données 24 heures par jour, sept jours par semaine, fournissant ainsi aux planificateurs la capacité de mesurer la congestion non récurrente, les temps de déplacement et la fiabilité des horaires de voyage, ainsi que d’autres aspects du rendement du système et de la fiabilité des services dans tous les modes de transport.

L’architecture régionale des STI fournit un guide pour l’archivage des données relatives au transport, y compris la collecte de données provenant de divers systèmes d’exploitation des STI. Ces capacités d’archivage tournent autour d’exemples régionaux d’une entité de l’architecture des STI pour le Canada, à savoir le sous-système de gestion des données archivées. De plus, l’architecture régionale des STI aura des exemples régionaux de services STI, comme un mini-entrepôt de données sur les STI (ensemble de données historiques provenant d’une seule source) et un entrepôt de données sur les STI (ensemble de données historiques provenant de multiples aspects du transport). Ces exemples régionaux de services décrivent des connexions et des renseignements qui peuvent être utiles aux planificateurs dans leur travail d’évaluation et de priorisation. Alors que l’automatisation de la collecte des données aux fins de l’archivage soit habituellement une activité ultérieure (ou un projet futur), les discussions qui ont lieu durant l’élaboration de l’architecture régionale des STI présentent souvent des possibilités additionnelles de partage des données qui surviennent immédiatement, ou même avant que des projets d’automatisation du partage des données soient mis en oeuvre. Ce partage des données entre l’exploitation et la planification, de même que la coordination qui survient lors de l’élaboration de l’architecture régionale des STI sont des exemples de liens entre la planification et l’exploitation.

Les extrants de l’architecture régionale des STI, en particulier ceux du séquençage des projets, peuvent aussi être fort utiles aux planificateurs en tant qu’aide à l’évaluation et à la priorisation. L’architecture fournit une perspective multimodale à court et à long terme des STI dans la région. Elle fournit des renseignements détaillés sur les services et les fonctions de transport que les intervenants assurent dans le cadre de projets de STI. L’architecture régionale des STI illustre également les interfaces nécessaires entre les systèmes de transport pour répondre aux besoins en transport dans la région. Elle exprime cette information par la définition d’un ensemble de projets qui doivent être mis en oeuvre. Habituellement, elle classe ces projets en fonction d’un calendrier (par ex., à court, moyen ou long terme). Un élément clé de l’utilité de l’architecture relativement à l’évaluation et à la priorisation des stratégies (ainsi qu’au PLT, comme nous le verrons plus loin) tient au fait que cette liste de projets va au-delà des projets à court terme. Le séquençage des projets contient des renseignements sur chaque projet qui peuvent être utiles pour l’évaluation et l’établissement des priorités des projets, y compris des renseignements sur :

• les intervenants;
• les coûts;
• les avantages;
• la correspondance avec les services STI.

Il convient de noter que le séquençage des projets ne remplace pas la priorisation. En fait, il est plutôt un intrant au processus de priorisation. Dans certaines régions, la priorisation pourrait déjà être reflétée dans les extrants du séquençage des projets.

Une architecture régionale des STI fournit un guide sur la manière dont les projets de STI peuvent être déployés pour satisfaire à la vision et aux buts définis comme faisant partie du processus de planification. L’architecture régionale des STI fournit des renseignements détaillés sur la manière dont les STI peuvent être déployés afin de satisfaire aux stratégies et aux services de transport dans la région. Cette information pourrait inclure les interfaces, les concepts d’exploitation et les ententes requises pour mettre en oeuvre les stratégies et les services de transport. Grâce à cette information détaillée, les projets de STI peuvent être définis avec plus de clarté, financés et mis en oeuvre afin de satisfaire aux buts régionaux.

Plan à long terme

Une des principales raisons des STI et de l’architecture régionale des STI est le besoin d’une gestion plus efficace de l’infrastructure de transport existante. Beaucoup de régions ne peuvent plus ajouter simplement une capacité afin de suivre le rythme de la demande croissante. Elles doivent plutôt miser sur une gestion plus efficace et intégrée de l’infrastructure de transport existante. Parce qu’elles reconnaissent cette nécessité, bon nombre de régions commencent à inclure dans leur PLT une section portant sur la gestion et l’exploitation, qui peut se définir comme une approche intégrée visant à optimiser le rendement de l’infrastructure existante grâce à la mise en oeuvre de systèmes, de services et de projets multimodaux, intermodaux et intergouvernementaux.

Un des principaux buts de l’architecture régionale des STI est de définir la manière dont un système intégré de transport ou des composants STI peuvent se développer dans une région. Pour ce faire, l’architecture décrit les éléments (par ex., les divers composants STI) qui sont interreliés pour fournir l’exploitation et la gestion du système de transport. Le processus d’élaboration et d’entretien de l’architecture permet aux planificateurs du transport de se concentrer davantage sur la gestion intégrée et l’exploitation. Les responsables de l’exploitation ont une vision de la manière dont le système intégré de transport peut se développer, et ils expriment cette vision dans l’information détaillée sur l’architecture.

Une section portant sur la gestion et l’exploitation devrait être envisagée dans tous les plans à long terme liés à des architectures régionales des STI, y compris les plans élaborés par les organismes, les régions métropolitaines et les provinces. Une telle section établit un lien entre le plan du système intégré d’une architecture et le processus global de planification du transport. Elle peut servir à décrire (au niveau des renseignements appropriés au PLT) la partie STI de la vision du transport régional. Certaines régions intègrent explicitement leur architecture des STI à cette section du PLT en tant que partie intégrante, alors que d’autres l’incluent simplement à titre de référence.

Puisque l’architecture régionale des STI peut soutenir directement l’élaboration du plan à long terme (de même que les activités d’évaluation utilisées pour élaborer le plan), il est recommandé que l’architecture soit adoptée officiellement par l’organisation responsable de la planification régionale. Idéalement, l’adoption de l’architecture devrait survenir à la fin de son élaboration initiale. L’adoption officielle de l’architecture régionale des STI présente certains avantages. Elle ajoute une crédibilité à l’architecture, en permettant aux planificateurs d’utiliser des aspects de l’architecture en sachant que la région les a acceptés. L’adoption officielle de l’architecture apporte une rigueur additionnelle dans le processus de son entretien. Cette recommandation n’est pas pratique dans toutes les situations en raison de complexités institutionnelles ou parce que l’architecture a une portée géographique différente (par ex., plus grande) de celle de l’organisation responsable de la planification régionale.

L’entretien permanent de l’architecture (qui est abordé à la section 8) relève généralement de l’organisation régionale responsable de la planification qui assume souvent la responsabilité d’établir les processus aux fins de l’utilisation de l’architecture dans la planification, la programmation et la mise en oeuvre des projets.

Participation des intervenants

Une architecture régionale des STI fournit une vision de la manière dont les systèmes de transport intelligents et les projets qui leur sont associés peuvent être déployés afin d’atteindre les buts et les objectifs soulignés dans le plan à long terme. La participation d’un bassin important d’intervenants est essentielle à l’élaboration et à l’entretien de l’architecture régionale des STI. À partir de la portée de l’architecture, les intervenants peuvent (et doivent) aller au-delà des organismes axés traditionnellement sur l’élaboration du PLT. Les intervenants, comme les responsables de la sécurité publique, les exploitants de véhicules commerciaux, les agences de tourisme, les médias et les fournisseurs de services de transport pourraient participer au travail d’élaboration et d’entretien de l’architecture régionale des STI.

Les efforts consacrés à l’élaboration de l’architecture ont un deuxième effet positif sur la participation des intervenants au processus de planification. L’architecture sert de point d’intérêt pour la coordination et la collaboration entre les planificateurs et les responsables de l’exploitation. Elle peut aussi favoriser la participation des gestionnaires de l’exploitation à la planification régionale. L’architecture définit des services particuliers, des interconnexions et des projets sur un horizon temporel qui coïncide avec le calendrier du PLT. En encourageant les responsables de l’exploitation à prévoir une évolution de leurs systèmes au-delà des projets actuels, l’architecture relie leur réflexion à long terme à celle des planificateurs du transport. L’architecture régionale des STI est une des possibilités d’améliorer l’interrelation entre la planification et l’exploitation.

Bien que son but central soit de fournir une structure aux composants techniques et de permettre que l’interdépendance entre les systèmes soit établie, une architecture régionale des STI peut aussi contribuer grandement à la mobilisation des intervenants, notamment parce qu’elle démontre l’interdépendance institutionnelle qui existe dans une région et comment chaque organisme peut tirer avantage des activités des autres.

Puisqu’elle inclut une comptabilisation complète de l’inventaire des STI actuels et prévus, l’architecture régionale peut servir à obtenir l’adhésion de tous les intervenants et à faire connaître leurs besoins. Les applications des STI allant souvent au-delà des limites modales ou institutionnelles, une architecture peut aider les intervenants à déterminer les secteurs où les ressources et le financement peuvent être accrus au moyen de la coopération interorganismes.

Dans la mesure où la planification du transport et l’élaboration de l’architecture encouragent le renforcement du travail d’équipe et le dialogue, il y a de fortes chances que la collaboration établie puisse être utilisée pour aborder d’autres questions non liées à l’architecture. En plus de motiver davantage les participants à la planification traditionnelle, une architecture régionale des STI peut aider à mobiliser de nouveaux participants.

La discussion précédente sur la manière dont l’architecture régionale des STI soutient l’élaboration du PLT pourrait avoir limité l’applicabilité, étant donné l’état actuel de l’architecture régionale des STI et la structure actuelle du PLT. Toutefois, l’architecture régionale des STI et le plan stratégique des STI (qui sera abordé plus bas) seront mis à jour périodiquement afin de soutenir les mises à jour du PLT (voir l’entretien de l’architecture des STI à la section 8). À chaque mise à jour de l’architecture, tenez compte des changements apportés aux extrants de l’architecture qui fourniront un soutien accru au PLT. La Figure 20 illustre cette idée de la mise à jour de l’architecture régionale des STI et du plan stratégique des STI correspondant afin d’améliorer leur capacité de soutenir le PLT.

7.1.2 Plans stratégiques des STI

Un plan stratégique des STI (appelé aussi « évaluation stratégique des STI » ou « plan de déploiement des STI ») est un guide pour la mise en place des STI dans une région. Un plan semblable peut résulter du travail global d’élaboration de l’architecture régionale des STI ou d’un autre travail distinct. Dans le premier cas, le plan stratégique des STI peut être l’un des nombreux documents produits durant l’élaboration de l’architecture. Dans certains cas, l’architecture régionale des STI est simplement une partie d’un travail plus vaste et représente une partie de toute la documentation relative au plan stratégique des STI. Dans des exemples plus récents où un plan stratégique des STI a été créé dans le cadre d’efforts non axés sur l’élaboration de l’architecture, cette dernière est référencée dans le plan. La Figure 21 montre que, peu importe la forme ou la relation qui existe entre l’architecture et le plan stratégique des STI, ce travail peut être utilisé pour soutenir le plan à long terme et le programme de planification des immobilisations (qui est abordé à la section 7.2).

Pourquoi des régions ont-elles créé des plans stratégiques des STI? Parce qu’elles ont estimé que ces plans étaient une façon utile de définir leurs besoins en STI et de fournir un intrant au processus officiel de planification. Des régions ont utilisé des plans stratégiques des STI en tant que ponts entre l’information détaillée sur l’architecture et les discussions autour de la planification du transport contenues dans le plan à long terme.

Souvent, les plans stratégiques des STI contiennent certains des extrants de l’architecture. Les extrants les plus courants de l’architecture inclus dans les plans stratégiques des STI sont la définition de la séquence des projets et la liste des ententes interorganismes, comme nous l’avons vu à la section 6.

La grande particularité de ces plans tient au fait qu’ils contiennent habituellement des éléments qui vont au-delà de l’ensemble des exigences relatives à la politique ou à la règle. Parmi les éléments souvent inclus dans les plans stratégiques des STI (et qui peuvent aider à établir un meilleur lien entre l’architecture des STI et les plans de transport régional), mentionnons les suivants :

• Vision STI : Cet énoncé concis qui fournit les raisons pour lesquelles la région déploie des STI peut servir de lien vers la vision plus large du transport articulée dans le plan à long terme.
• Besoins, buts et objectifs couverts par les STI : L’établissement des besoins, des buts et des objectifs (et des politiques, dans certaines régions) couverts par les STI fournit un lien direct avec les besoins, les buts et les objectifs qui sont à la base du plan à long terme. Une excellente façon d’incorporer des projets de STI au processus de planification régionale consiste à relier les déploiements de STI et les enjeux plus larges associés au transport.
• Stratégies de déploiement des STI : La planification du transport tend à articuler des « stratégies » en matière de transport régional. L’architecture régionale des STI, telle qu’elle a été décrite dans les sections précédentes, contient des éléments particuliers, des services, des échanges d’information et des projets en tant qu’extrants. Dans la liste courante des extrants de l’architecture, il manque une stratégie relative à la manière dont les STI seront déployés au fil du temps. C’est pourquoi beaucoup de régions ajoutent une stratégie de déploiement à leur plan stratégique des STI.
• Considérations relatives au financement : Les sources de financement et les exigences relatives au financement des déploiements des STI pourraient être examinées. À cette fin, certains aspects des déploiements doivent être évalués. Les questions liées au financement de l’exploitation et à l’entretien des systèmes sont particulièrement importantes en regard des déploiements des STI.
• Définitions détaillées des projets : L’architecture régionale des STI peut définir des projets régionaux de manière générale, et plus tard, ces projets peuvent être définis de manière plus particulière dans le plan stratégique. Par exemple, un projet général de surveillance dans une zone métropolitaine pourrait être divisé en plusieurs projets correspondant à des étapes. Ces projets pourraient ajouter une instrumentation aux différentes composantes de la région métropolitaine au fil du temps. Les projets localisés pourraient être coordonnés avec d’autres améliorations prévues aux immobilisations, et les endroits prioritaires seraient instrumentés en premier à mesure que les fonds seraient disponibles. Des définitions plus détaillées des projets localisés sont requises pour estimer les coûts avec précision.
• Lacunes dans les projets prévus : L’architecture régionale des STI suggère des composants, des services et des échanges d’information qui seront mis en place selon le calendrier prévu. Les projets énumérés dans l’architecture mettent en oeuvre invariablement un seul sous-ensemble des parties de l’architecture. L’établissement des « écarts » entre la liste des projets et l’architecture, ainsi que la priorisation de ces écarts ou de ces lacunes permettent souvent de comprendre où des projets additionnels pourraient être nécessaires pour répondre à des besoins prioritaires.
• Analyse des avantages : Puisque les projets de transport sont « cotés », en dernier ressort, selon le rapport coûts-avantages à mesure qu’ils s’orientent vers la phase de programmation, il peut être utile de discuter précisément des coûts et des avantages des projets de STI. Cette discussion pourrait faire partie intégrante de l’extrant du séquençage des Document d’orientation sur l’architecture régionale des STI Utilisation dans une planification 125 projets ou du plan stratégique des STI, selon l’approche adoptée par la région.
• Plan de communications : L’architecture est axée sur les services de transport, mais l’infrastructure de communication qui les soutient est essentielle à la mise en oeuvre réussie des projets de STI. C’est pourquoi certaines régions créent des plans de communications qu’elles intègrent à leurs plans stratégiques afin de déterminer les enjeux, les stratégies et les solutions en rapport avec cet aspect important que sont les déploiements des STI.

Le commun dénominateur dans ce qui précède est le désir de mieux relier les déploiements des STI (tels qu’ils sont décrits dans l’architecture régionale) au processus de planification du transport (tel qu’il est décrit dans le plan à long terme). Le plan stratégique des STI met l’accent sur les stratégies en matière de gestion et d’exploitation (parce que les services STI sont axés sur ces stratégies), un aspect essentiel au PLT.

7.1.3 Autres activités de planification

Comme le montre la Figure 22, diverses autres activités de planification fournissent des intrants au PLT. Ces activités peuvent être soutenues par des extrants de l’architecture régionale des STI.

Processus de gestion de la congestion

Le processus de gestion de la congestion (PGC) peut être défini de la manière suivante : « À l’intérieur d’une zone de planification métropolitaine qui dessert une zone de gestion du transport, le processus de planification du transport, tel qu’il est défini dans la présente section, s’occupe de la gestion de la congestion à l’aide d’un processus qui prévoit l’exploitation et l’entretien efficaces, à partir d’une stratégie métropolitaine élaborée et mise en oeuvre en collaboration, des installations de transport, nouvelles et existantes, admissibles à un financement en vertu de la présente section et comme en fait foi la Figure 23, grâce à l’utilisation de stratégies en matière de réduction de la demande en transport et en matière de gestion opérationnelle ». Les exigences relatives au PGC n’ont pas été modifiées par la nouvelle législation. (À noter que les planificateurs connaissent le PGC sous son ancienne appellation de système de gestion de la congestion. La Figure 23 présente un aperçu des étapes du processus de gestion de la congestion, ainsi que les endroits où des liens peuvent exister avec l’architecture régionale des STI.

Voici les principales étapes du processus de gestion de la congestion et comment l’architecture régionale des STI peut soutenir ces activités.

La première étape du processus consiste à élaborer des mesures de rendement qui définissent la congestion dans la région et les moyens de l’atténuer. Ces mesures serviront à déterminer la congestion et soutenir l’évaluation de l’efficacité des stratégies en matière de réduction de la congestion. L’architecture régionale des STI peut définir les sources de données opérationnelles qui peuvent être utilisées pour réaliser les activités de mesure. De plus, l’architecture définit un ensemble d’interfaces qui peuvent soutenir les mesures de rendement. Il est suggéré que ces mesures tiennent compte aussi bien la congestion récurrente que la congestion non récurrente. À noter que les stratégies liées aux STI s’avèrent particulièrement efficaces pour aborder la question de la congestion non récurrente.

Pour déterminer l’envergure, la durée et les causes de la congestion, des capacités de collecte de données ou de surveillance de la circulation doivent être mises en place. Beaucoup de capacités de collecte de données (existantes ou nouvelles) sont des capacités des STI et, à ce titre, devraient être incluses dans l’architecture régionale des STI. Là où des projets doivent être mis en oeuvre pour fournir des capacités de collecte de données ou de surveillance de la circulation, l’architecture régionale des STI, par le truchement de l’extrant du séquençage des projets, définira les projets en question.

L’étape suivante du processus de gestion de la congestion consiste à définir et à évaluer les stratégies de réduction de la demande en transport et les stratégies de gestion opérationnelle. Ces stratégies représentent un sous-ensemble des stratégies régionales globales qui font partie intégrante du processus de planification, comme l’a montré la Figure 19. À ce titre, l’architecture régionale des STI définit les services qui peuvent être inclus dans la boîte à outils des stratégies STI de gestion de la congestion.

La surveillance de l’efficacité des stratégies choisies nécessite l’évaluation de l’efficience et de l’efficacité des mesures de gestion de la congestion mises en place, dont certaines représentent des projets de STI décrits par l’architecture régionale des STI. L’évaluation implique l’examen des mesures de rendement au moyen de capacités, telles que des capacités de collecte des données ou de surveillance de la circulation. Comme nous l’avons souligné, bon nombre de ces capacités sont définies dans l’architecture régionale des STI, à partir d’une description des systèmes et des interfaces, de même que de la définition des projets mis en oeuvre pour fournir les capacités.

Finalement, le PGC implique le besoin de documenter les étapes précédentes et leurs résultats, ainsi que la définition d’un processus d’évaluation périodique de l’efficience et de l’efficacité des stratégies mises en place en fonction des mesures de rendement établies dans la région.

Planification de la sécurité

La planification de la sécurité devrait avoir pour but d’atteindre une réduction importante des décès et des blessures graves sur toutes les routes publiques.

• des représentants de la sécurité routière du gouvernement provincial;
• des représentants d’organismes de planification du transport régional et d’organismes de planification métropolitaine;
• des représentants des principaux modes de transport;
• des responsables provinciaux et locaux de l’application des règlements de la circulation;
• des représentants de l’Opération Gareautrain;
• des représentants de programmes de sécurité destinés aux transporteurs routiers;
• des représentants d’organismes responsables de la gestion des véhicules à moteur;
• d’autres intervenants majeurs, provinciaux et locaux, concernés par la sécurité.

Le plan devrait aborder des éléments propres à la sécurité routière, en tant que facteurs clés dans l’évaluation des projets routiers, comme l’ingénierie, la gestion, l’exploitation, l’éducation, l’application de la loi et les services d’urgence (incluant les communications d’urgence intégrées et interopérables). L’architecture régionale des STI peut soutenir l’élaboration de ces plans de diverses façons, dont les suivantes :

• l’interaction des intervenants;
• la définition des services associés à la sécurité; la définition des projets visant à mettre en place ces services de sécurité.

La liste des intervenants concernés par l’élaboration du plan de sécurité contient les noms de nombreux intervenants concernés par l’élaboration de l’architecture régionale des STI. Le processus de création d’une architecture régionale des STI favorise le regroupement de divers intervenants, en plus de faciliter les communications et les consensus, deux éléments fort utiles lors de l’élaboration du plan de sécurité.

Certaines des solutions aux problèmes de sécurité incluses dans le plan stratégique de sécurité routière sont des services STI contenus dans l’architecture régionale des STI qui, comme on le sait, décrit les systèmes, les interfaces et les flux d’information qui définissent les services. Les extrants de l’architecture régionale des STI pourraient être utilisés directement dans le plan de sécurité pour décrire les solutions STI connexes.

Finalement, l’extrant du séquençage des projets de l’architecture régionale des STI contient des projets concernent des questions relatives à la sécurité. L’information découlant du séquençage des projets peut être utilisée aux fins de l’élaboration du plan de sécurité.

Activités de planification additionnelles

Une architecture régionale des STI peut soutenir diverses autres activités de planification réalisées fréquemment au niveau régional ou provincial, notamment :

• la planification du fret;
• la planification de la sécurité;
• la planification opérationnelle.

Bon nombre de provinces abordent la planification du fret dans le cadre de leur travail de planification à long terme. Certaines adoptent une approche active, en décrivant les mouvements de fret sur l’ensemble de leur territoire ou dans des zones métropolitaines, quand elles élaborent des plans de fret multimodal autonome et intégré. D’autres provinces ont commencé à concevoir des outils analytiques, ou des programmes de collecte de données sur le fret, afin d’élaborer des mesures de rendement du fret ou d’orienter les politiques en matière de fret et les décisions d’investissement dans le transport. La planification du fret couvre les étapes de base du processus de planification mentionnées à la Figure 19 – à savoir établir les buts ou les besoins, élaborer des stratégies pour atteindre ces buts ou répondre à ces besoins, évaluer les stratégies et documenter les stratégies recommandées. Une architecture régionale des STI pourrait être utilisée lors de ces étapes, si elle a pris en considération les services liés au fret. Elle pourrait alors être utilisée de la même manière que dans le cas de la planification à long terme, dont il a été question à la section 7.1.1. En outre, les aspects de l’architecture relatifs à l’exploitation des véhicules commerciaux pourraient s’avérer une source d’information utile sur les intervenants, les services, les interfaces et les flux d’information qui influent indirectement sur la gestion du fret.

La planification de la sécurité pourrait aborder de multiples facettes de la sécurité tels que la sécurité informatique, la sécurité opérationnelle, la sécurité du personnel et la gestion de la sécurité. La sécurité informatique consiste à protéger le point d’origine, la transmission et le point de destination de l’information. La sécurité opérationnelle a pour principale responsabilité la protection des éléments de transport contre des menaces physiques et environnementales. La sécurité du personnel s’assure que les employées affectés au transport ne causent pas de dommages, par malice ou inadvertance, aux éléments essentiels aux STI et qu’ils ont une formation appropriée en cas d’incident lié à la sécurité. La gestion de la sécurité fournit le fondement d’autres domaines de sûreté et aborde, entre autres choses, la politique en matière de sécurité des systèmes. Une architecture régionale des STI établit les services associés à la sécurité qui s’appliqueraient à l’élaboration de ces types de plans.

La planification opérationnelle inclut des éléments, comme la planification du niveau d’investissement requis dans les organismes pris individuellement, en couvrant des domaines comme les services de sécurité, le personnel, les activités d’entretien, les services de transport en commun, etc. L’architecture régionale des STI (ou le plan stratégique des STI) peut soutenir des aspects de ces plans en utilisant l’extrant du séquençage des projets ou la description des services qu’elle contient.

7.2 Use for Programming/Budgeting/Capital Planning

Regional and province-wide programming and agency capital planning (a.k.a. budgeting) involve identifying and prioritizing ITS projects. The result is funded projects. These processes are shown in Figure 24.

L’utilisation d’une architecture régionale des STI pour définir un projet de STI établit un lien entre les objectifs et les besoins de la région dans l’architecture, d’une part, et les STI déployés sur le terrain, d’autre part. Dans une région, les projets de STI sont déployés par de nombreux organismes, y compris le ministère provincial des Transports, les sociétés de transport en commun et d’autres organismes locaux. Si les projets des divers organismes concernés sont définis à partir d’un même point de repère, à savoir l’architecture régionale des STI, la coordination commence par la phase initiale de planification et de financement.

Utilisation de l’architecture dans la planification des immobilisations

Tous les organismes (ministères provinciaux des Transports, sociétés de transport en commun, municipalités, etc.) ont recours à un processus budgétaire pour allouer des fonds aux projets retenus. Une architecture régionale des STI devrait inclure les composants existants et prévus de tous les intervenants. Elle devrait aussi décrire comment ces éléments sont ou seront interfacés avec d’autres composants STI dans la région. Ainsi, tous les organismes peuvent utiliser l’architecture régionale des STI pour définir des projets de STI, comme nous le verrons plus loin, et les incorporer à leur processus budgétaire.

Utilisation de l’architecture pour établir et définir des projets

Une architecture régionale des STI inclut une séquence de projets, comme nous l’avons vu à la section 6. Les projets issus de l’architecture devraient être incorporés aux processus de programmation ou de planification des immobilisations.

Des organismes et des régions ont créé et utilisé des plans stratégiques des STI pour définir des projets de STI. Un plan stratégique détermine la vision STI de l’organisme ou de la région et la manière dont cette vision sera déployée. Un plan stratégique établit des projets localisés et le calendrier de leurs déploiements. Habituellement, un plan de déploiement est défini. Les projets de STI sont puisés directement dans le plan et soumis à des fins de financement (fédéral ou autre).

À mesure que les projets définis dans une architecture régionale des STI sont séquencés et acquièrent des caractéristiques propres (voir la section 6 sur le séquençage des projets), comme c’est le cas dans un plan stratégique, les organisations peuvent utiliser l’architecture pour définir des projets qui doivent être soumis à des fins de financement de quelque source que ce soit.

Pour obtenir un financement, le promoteur d’un projet doit le définir. L’information contenue dans une architecture régionale des STI peut être utilisée pour définir des projets plus en détail afin de mieux déterminer leur portée et leurs exigences budgétaires.

On peut utiliser une architecture régionale des STI pour définir un projet de STI de diverses façons, dont les suivantes :

• Examiner la liste des intervenants pour repérer ceux qui devraient être concernés par le projet, ainsi que ceux sur qui le projet a ou pourrait avoir des répercussions.
• Utiliser les rôles et les responsabilités des intervenants définis dans le concept d’exploitation afin de définir clairement les rôles et les responsabilités des intervenants concernés par le projet.
• Examiner le ou les services connexes (c.-à-d. les ensembles de solutions applicatives) pour établir les éléments directement ou indirectement associés au projet, puis reconnaître les partenaires potentiels en prévision du partage des coûts de l’élaboration, du matériel, de la main-d’oeuvre, des installations, etc.
• Utiliser les interfaces définies entre les composants STI afin de déterminer les possibilités d’intégration actuelles et futures.
• Utiliser la séquence des projets pour acquérir une connaissance approfondie du calendrier d’exécution du projet et de son interdépendance avec d’autres projets, y compris l’établissement des possibilités de coordination avec des projets d’immobilisations.
• Appliquer la description du projet au séquençage des projets, y compris les coûts et les avantages, la faisabilité technique, les questions institutionnelles potentielles et l’état de préparation afin de définir clairement le projet.
• Acquérir une compréhension approfondie des éléments et des interfaces contenus dans un projet afin d’évaluer les budgets des projets avec plus de précision.

Clé du succès (processus recommandé)

Le problème le plus difficile à résoudre dans l’intégration d’une architecture régionale des STI au processus de planification du projet tient au fait qu’il existe plus d’un processus de planification dans une région. La coordination est cruciale entre le ministère provincial des Transports et toutes les organisations en ce qui concerne leurs programmes, leurs budgets ou les plans d’immobilisations respectifs.

Pour s’assurer que les STI sont déployés à partir de la vision régionale contenue dans l’architecture régionale, il convient de mettre en place un processus de planification locale et régionale, ainsi qu’un processus de financement des projets prévus dans l’architecture. Des politiques et des procédures visant à incorporer les projets de STI au processus de programmation et au processus budgétaire peuvent être clairement établies, ou encore un groupe d’intervenants peut se voir confier la responsabilité de surveiller le déploiement des STI dans la région. Les processus de déploiement des projets varient d’une région à l’autre. Il convient donc d’adapter aux processus de la région le déploiement des projets de STI en fonction de l’architecture.

7.3 Utilisation dans la mise en oeuvre des projets

Une fois qu’un projet de STI a obtenu un financement et que sa mise en oeuvre débute, on a naturellement tendance à mettre l’accent sur l’information relative aux programmes et aux données techniques du projet et à perdre de vue le contexte régional plus large dans lequel il s’inscrit. L’utilisation de l’architecture régionale des STI dans la mise en oeuvre des projets fournit ce contexte. Elle donne à chaque promoteur l’occasion de situer son projet par rapport aux systèmes environnants en l’amenant à réfléchir à la manière dont son projet correspond à la vision globale du transport dans la région. L’utilisation de l’architecture régionale des STI détermine les possibilités d’intégration qui devraient être examinées, en plus de fournir un bon point de départ pour l’analyse de l’ingénierie des systèmes que les projets de STI requièrent.

7.3.1 Cycle de vie de l’élaboration des projets

Comme on le sait, les projets de transport sont définis et financés lors des phases de la planification du transport et de la programmation ou de l’établissement du budget. Une fois financés, les projets sont mis en oeuvre à l’aide d’un processus qui varie d’un projet à l’autre. Par exemple, les projets de STI qui installent des dispositifs sur le terrain (par ex., des panneaux à messages variables) recourent à un processus qui s’apparente au processus d’élaboration de projets traditionnels illustré à la Figure 25. Les projets de STI qui incluent la préparation et l’intégration d’un matériel informatique et de composants logiciels nécessitent des analyses additionnelles de l’ingénierie des systèmes qui sont comme des prolongements du processus d’élaboration des projets traditionnels.

Tandis que les processus d’élaboration des projets varient d’une province à l’autre et d’une organisation à l’autre dans chaque province, les processus d’élaboration des projets tendent à avoir les mêmes étapes principales. Lancement des projets – Le gestionnaire de projet est choisi, l’équipe du projet est formée et l’élaboration du projet est planifiée. Une définition à niveau élevé du projet est élaborée, les coûts sont évalués, les listes de vérification sont dressées et les formulaires requis sont remplis aux fins de l’approbation du projet par son promoteur et l’organisme ou les organismes de financement. L’architecture régionale des STI peut être utilisée pour déterminer la portée du projet, repérer les intervenants concernés, déterminer les rôles et les responsabilités de niveau élevé, la partie de l’architecture qui doit être mise en oeuvre, ainsi que la phase du séquençage des projets dans laquelle le projet se situe.

• Ingénierie préliminaire – Dans les processus d’élaboration des projets d’immobilisations traditionnels, des études (études environnementales, études sur des tracés, etc.) sont réalisées selon le type de projet. Ces études aident à mieux comprendre les exigences et les contraintes relatives aux projets. Les projets de STI qui incluent des travaux de construction requièrent les mêmes études, ainsi que des analyses additionnelles d’ingénierie, pour préciser les exigences relatives aux composants STI des projets. L’architecture régionale des STI peut contribuer à la préparation de ces analyses d’ingénierie préliminaire, puisqu’elle contient des exigences fonctionnelles de niveau élevé et des définitions d’interfaces qui peuvent servir de point de départ. À noter que, dans la perspective d’une aide fédérale, le terme « ingénierie préliminaire » inclut également les plans, les devis et les estimations – qui sont séparés ici pour marquer la différence entre l’étape des exigences et l’étape de la conception dans le processus d’élaboration des projets traditionnels.
• Plans, devis et estimations – La conception détaillée d’un projet, accompagnée des spécifications propres au projet, de même que les estimations des besoins en matériaux et des coûts sont documentées. Dans un projet de construction traditionnel, cette étape du processus fournit aux compagnies toute l’information dont elles ont besoin pour préparer une soumission en bonne et due forme. Les éléments de construction dans le cadre d’un projet de STI requièrent aussi une documentation sur la conception traditionnelle (les esquisses, les maquettes, les vues en plan, les vues de face, les profils en travers, etc.). Une documentation sur la conception est aussi requise pour un matériel informatique et des composants logiciels, mais elle prend la forme d’une conception de niveau élevé, de spécifications des interfaces, du matériel informatique et des logiciels. À cette étape, l’architecture fournit un intrant, y compris l’information sur les normes STI qui pourraient être pertinentes en regard du projet.
• Construction – Le projet est exécuté. Dans le cas d’un projet de transport traditionnel, la construction prend la forme d’une amélioration physique. S’il s’agit d’un projet de STI, l’étape de la construction inclut la mise en place du matériel informatique, des composants logiciels et des autres produits clés (manuels, procédures opérationnelles, documents de formation, etc.). Cette étape inclut également l’inspection de l’amélioration ou des améliorations physiques, ainsi que l’intégration et la mise à l’essai du ou des systèmes mis en place.
• Clôture des projets – Après l’inspection et la mise à l’essai finales, le projet achevé est accepté, les plans conformes à l’exécution sont créés et un dossier sur l’historique du projet est achevé.

Comme on le voit, le moment le plus propice pour utiliser l’architecture régionale des STI est tôt dans le processus d’élaboration, lorsque le projet démarre et que l’ingénierie préliminaire est réalisée. L’architecture est plus intéressante en tant qu’outil permettant à un projet d’être défini plus largement et dans le contexte régional. Aux étapes subséquentes, lorsque la portée du projet est clairement établie et que le projet est défini en détail, il y a moins de possibilités d’utiliser les définitions de niveau élevé contenues dans l’architecture régionale des STI. Une orientation plus détaillée de l’utilisation de l’architecture régionale des STI à chacune des étapes du processus d’élaboration des projets est présentée plus loin dans le présent document.

Rôles dans l’élaboration des projets

Vous devez prendre en considération divers rôles lorsque vous envisagez d’élaborer une façon d’utiliser l’architecture des STI dans votre région, dont les suivants :

• Promoteur du projet – C’est l’organisme ou le groupe qui préconise le projet et assume la responsabilité de son élaboration. Il peut s’agir de n’importe quel organisme actif dans la région – une municipalité, un comté, le ministère provincial des Transports, un organisme responsable de la sécurité publique, Transports Canada, etc.
• Spécialiste de l’entretien de l’architecture – C’est l’organisme qui a la responsabilité de soutenir et d’entretenir l’architecture régionale des STI.
• Gestionnaire de projet – Responsable de la réalisation et de la gestion du projet, cet individu s’assure que le projet satisfait aux exigences relatives à l’échéancier, aux coûts et aux besoins du client.
• Équipe du projet – Toutes les personnes qui travaillent à la réalisation du projet, y compris les employées de l’organisme ou des organismes participants, les consultants et les entrepreneurs.

Problèmes et solutions dans l’utilisation de l’architecture

Les régions doivent résoudre quelques problèmes pour que l’architecture régionale des STI puisse être utilisée efficacement afin de soutenir l’élaboration des projets. Dans l’ensemble du pays, des régions sont confrontées aux mêmes problèmes, et de nouvelles pratiques exemplaires encouragent une utilisation bénéfique de l’architecture. Voici cinq problèmes courants et leurs solutions correspondantes.

1. Problème : Bien que la responsabilité de l’entretien de l’architecture relève normalement d’un seul organisme, beaucoup d’organismes dans une région sont les promoteurs ou les parrains du projet qui utiliseront l’architecture.

   Solution : Si elle est utilisée, l’architecture régionale des STI doit être facilement accessible à tous les promoteurs de la région. La version la plus récente de l’architecture doit être disponible à un endroit auquel tous les membres de l’équipe du projet peuvent avoir facilement accès. Idéalement, une page Web de l’architecture devrait fournir un accès à l’information et aux ressources les plus récentes. Le formulaire relatif à la documentation sur l’architecture doit pouvoir être facilement copié et collé dans la documentation sur le projet.

2. Problème : Chaque organisme promoteur du projet a son propre processus d’élaboration qu’il doit adapter aux fins de l’utilisation de l’architecture régionale des STI, si cette utilisation doit être systématique dans la région.

   Solution : Les points de contrôle où l’architecture devrait être utilisée dans l’élaboration des projets devraient être documentés officiellement au niveau de la province ou de la région. En particulier, un point de contrôle devrait être établi là où l’équipe du projet devrait avoir tenu compte de l’architecture à mesure que la portée du projet était définie. Ainsi, des possibilités d’intégration pourront être examinées pour chaque projet de STI. De même, un point de contrôle ultérieur devrait être établi là où l’équipe du projet devrait avoir vérifié si le projet est conforme à la conception est compatible avec l’architecture et où elle devrait avoir constaté qu’une modification devait être apportée à l’architecture régionale des STI pour obtenir cette compatibilité.

   

3. Problème : Le gestionnaire de projet et l’équipe du projet ont peu d’expérience ou n’ont aucune expérience dans la gestion d’une architecture régionale des STI. Quoique le processus d’élaboration de l’architecture soit inclusif, de plus petits organismes pourraient ne pas y avoir participé, et quelques individus seulement rattachés aux organismes participants pourraient avoir acquis une expérience pertinente. Au fil du temps, le roulement du personnel peut diluer le savoir-faire associé à l’architecture.

   Solution : Même si tous ne sont pas des spécialistes de l’architecture, au moins un membre de l’équipe du projet doit pouvoir l’utiliser efficacement. Si l’équipe ne dispose pas de cette expertise, une assistance technique doit être fournie par le spécialiste de l’entretien de l’architecture ou une autre ressource pour que la partie de l’architecture pertinente au projet puisse être déterminée. La région devrait faciliter le plus possible l’utilisation de l’architecture, documenter les directives de cette utilisation dans la mise en oeuvre des projets et rendre l’assistance technique et la formation disponibles aux équipes des projets.

   1. Les équipes des projets devraient examiner la documentation sur l’architecture de manière critique en regard de la facilité de l’utilisation de l’architecture. Des régions pourraient estimer que leur architecture est techniquement fiable, mais qu’elle doit être examinée pour que les équipes des projets puissent l’utiliser plus facilement. Plus particulièrement, il devrait être facile pour les utilisateurs de naviguer entre une partie de la documentation sur l’architecture (par ex., un composant particulier de l’inventaire) et des parties connexes (par ex., les exigences fonctionnelles, les intervenants et les interfaces).
   2. L’architecture doit être soutenue par une feuille de route concernant son utilisation, disponible à toutes les équipes de projets. Cette feuille de route contient des directives étape par étape sur la manière dont la documentation sur l’architecture régionale devrait être utilisée aux fins de l’élaboration des projets.
   3. Si elle y a accès et qu’elle en a une bonne maîtrise, l’équipe du projet peut utiliser Turbo Architecture pour déterminer la partie de l’architecture régionale des STI incluse dans un projet. Bien que ce logiciel soit un excellent moyen d’utiliser l’architecture, il est peu probable que chaque membre de l’équipe y ait accès et puisse l’utiliser sans avoir reçu une certaine formation. Lorsqu’elle établit le processus d’utilisation de l’architecture, la région doit soutenir les équipes qui n’ont aucune expérience avec Turbo Architecture.
   4. La facilité d’utilisation doit s’accompagner d’un programme efficace visant à fournir aux équipes de projets l’assistance technique dont elles ont besoin relativement à l’utilisation de l’architecture. À mesure que cette aide est fournie, il est bon de rendre la documentation disponible à chaque équipe de projet, y compris une foire aux questions qui peut faciliter ultérieurement l’utilisation de l’architecture.
   5. Les plus grands organismes devraient avoir un spécialiste des STI qui pourrait être membre des équipes de projets et soutenir l’utilisation de l’architecture, de même que l’application appropriée du processus d’ingénierie des systèmes et des normes STI. Ce spécialiste viendrait se joindre à l’équipe qui, selon la nature du projet, pourrait regrouper des experts environnementaux, juridiques, techniques, etc.
   6. Une formation sur l’architecture régionale des STI et la manière de l’utiliser devrait être offerte aux promoteurs des projets. Le présent document d’orientation et le cours de formation de l’architecture des STI pour le Canada fournissent des renseignements généraux sur l’utilisation de l’architecture régionale des STI. Ces renseignements pourraient être utilisés comme point de départ et adaptés selon l’architecture de la région et le processus d’élaboration des projets.
   7. Pour vous assurer que les équipes de projets ont toute l’expertise requise, pensez à inclure dans les exigences relatives aux demandes de propositions la connaissance ou l’expérience de l’architecture régionale des STI et son utilisation dans le cadre de projets.
4. Problème : Les projets de STI sont localisés, et l’architecture régionale des STI est normalement définie à un niveau plus élevé. Par exemple, beaucoup de projets mettent en place des dispositifs sur le terrain qui sont généralement représentés au moyen d’un seul composant d’inventaire dans l’architecture.

   Solution : Afin d’utiliser efficacement l’architecture, l’équipe du projet doit combler l’écart entre l’architecture régionale des STI de niveau plus élevé et la définition stricte d’un projet particulier. Les différents niveaux d’abstraction constituent un obstacle potentiel qui peut être surmonté par l’orientation que la région donne à l’utilisation de son architecture. Par exemple, le schéma fonctionnel du projet dans un concept d’opération pourrait être plus spécifique que ce qui est représenté dans l’architecture régionale des STI, mais en demeurant rattachable à cette architecture.

   Bien que ce soit parfois bénéfique, faites preuve de vigilance lorsque vous ajoutez des renseignements détaillés à votre architecture régionale des STI pour décrire avec plus de précision des projets pris individuellement. Par exemple, une municipalité pourrait déployer des dispositifs sur le terrain dans le cadre de dix projets différents durant un certain nombre d’années. Il serait probablement une erreur d’inclure dix composants d’inventaire différents dans l’architecture régionale des STI qui représentent de manière spécifique l’équipement dans chaque projet prévu. L’architecture contiendrait beaucoup trop d’information détaillée au point où il serait plus difficile de l’entretenir.

5. Problème : Certains projets courants classés comme étant des projets de STI, comme les projets de synchronisation de feux de circulation, ont des répercussions sur un seul système et ont moins besoin d’utiliser l’architecture régionale des STI.

   Solution : Le but de l’utilisation de l’architecture et des exigences relatives à l’analyse de l’ingénierie des systèmes dans le cadre des projets de STI est de réduire les risques techniques et d’accroître les chances de réussite des projets. Parmi les projets qui bénéficieront le plus de l’utilisation de l’architecture, mentionnons :

   • les projets multimodaux ou plurigouvernementaux qui relient les systèmes de différents organismes;
   • les projets axés sur le développement de nouveaux systèmes qui doivent tenir compte d’exigences relatives à une intégration future.

   Les projets qui ont une portée limitée bénéficieront moins de l’utilisation de l’architecture, comme :

   • les projets visant l’installation de feux de circulation dans des secteurs ruraux isolés et d’autres projets qui offrent très peu de possibilités d’intégration future;
   • les projets visant à accroître l’étendue d’un système, mais qui n’ajoutent pas de nouvelles interfaces ou une nouvelle fonctionnalité (par ex., l’ajout de caméras de télévision en circuit fermé à un système existant);
   • les projets qui améliorent l’exploitation actuelle d’un système, mais qui n’ajoutent pas de nouvelles interfaces ou une nouvelle fonctionnalité, comme les projets de synchronisation de feux de circulation).

   L’utilisation de l’architecture offre des avantages, même dans le cadre des projets de STI plus simples. Par exemple, les projets de synchronisation de feux de circulation peuvent bénéficier de l’utilisation de l’architecture lorsqu’il est prévu d’intégrer des systèmes de signalisation routière adjacents.

7.3.2 Ingénierie des systèmes dans le cadre des projets de STI

L’architecture régionale des STI fournit un point de départ pour des analyses de l’ingénierie des systèmes réalisées durant l’élaboration de projets de STI. L’ingénierie des systèmes est une approche interdisciplinaire ayant pour objet la conception de systèmes. Elle est utilisée dans de nombreuses industries parce qu’elle contribue au succès des projets. Tout gestionnaire de projet souhaite que son projet réussisse, et le succès du projet est mesuré de deux façons :

1. par l’évolution des coûts et le respect de l’échéancier; 2
2. par la capacité des systèmes mis en place de satisfaire, en dernier ressort, aux besoins de leurs utilisateurs.

Le principal avantage de l’ingénierie des systèmes est qu’elle réduit le risque d’un dépassement des coûts et des délais prévus et qu’elle augmente les chances que les systèmes répondent aux besoins de leurs utilisateurs. Parmi les autres avantages courants, mentionnons ceux-ci :

• une meilleure documentation sur les systèmes;
• une plus grande participation des intervenants;
• des cycles de projets plus courts;
• des systèmes à tolérance de pannes qui peuvent évoluer sans nécessiter des modifications majeures;
• une réutilisation accrue des composantes;
• des résultats plus prévisibles.

Toute approche axée sur l’ingénierie des systèmes requiert une planification initiale et une définition des systèmes. Ainsi, on peut établir et documenter les caractéristiques du projet avant de faire des choix technologiques et de mettre en place les systèmes. À la gauche du diagramme, la définition des systèmes progresse à partir d’une vue utilisateur générale jusqu’à des données détaillées sur la conception des systèmes. À mesure que l’élaboration progresse, des données de base documentées sont établies et soutiennent les étapes subséquentes. Par exemple, un concept consensuel des opérations soutient l’élaboration des exigences inhérentes aux systèmes. Le matériel informatique et les composants logiciels sont mis en place durant le codage et la fabrication (indiqués au bas du diagramme), puis les composants des systèmes sont intégrés, testés et vérifiés de manière itérative (côté droit du diagramme). Une fois achevés, les systèmes sont validés pour déterminer dans quelle mesure ils satisfont aux besoins des utilisateurs. On constate une traçabilité d’une étape à l’étape suivante et entre les étapes, sur les deux côtés du diagramme, puisque la définition des systèmes qui est créée à la gauche est utilisée pour vérifier les systèmes à droite. Les besoins des utilisateurs, établis à la toute première étape du processus, servent à valider les systèmes, une fois achevés.

En plus des étapes du processus établies dans le diagramme en V, il existe diverses activités transversales qui contribuent au succès des projets. L’élaboration d’un plan de gestion de l’ingénierie des systèmes (PGIS), la gestion de la configuration, la gestion des risques et la surveillance des projets sont des pratiques exemplaires associées à l’ingénierie des systèmes qui bénéficient aux projets de STI.

Ingénierie des systèmes et processus d’élaboration de projets traditionnels

Le processus d’élaboration de projets de transport se développe depuis un siècle au moyen de la construction de routes et de systèmes de transport en commun. De nos jours, ce processus, utilisé par la plupart des organismes responsables du transport, inclut de nombreuses exigences propres au processus d’ingénierie des systèmes. Dans les deux processus, chaque système est défini dans des termes détaillés par les besoins d’abord, puis par les exigences et la conception. La communication et la sensibilisation entreprises systématiquement auprès des équipes de projets multidisciplinaires et des intervenants sont des marques d’un bon processus d’élaboration de projets de transport et d’un bon processus d’ingénierie des systèmes. En tirant avantage de concepts et de processus similaires, le processus d’ingénierie des systèmes peut être intégré au processus d’élaboration de projets de transport traditionnels en tant que prolongement.

En intégrant l’ingénierie des systèmes au processus d’élaboration de projets de transport traditionnels, il est plus facile d’incorporer l’architecture régionale des STI aux processus mis en place par les différents organismes concernés. Le processus d’élaboration de projets de transport est aussi influencé par la stratégie d’approvisionnement choisie. Des projets de STI ont été approvisionnés par le truchement de soumissionnaires moins-disants, de gestionnaires de système, de la conception-construction, de l’ordonnance des tâches et d’autres approches innovatrices en matière d’approvisionnement. La stratégie d’approvisionnement influencera l’organisation ou la personne (organisme, consultant ou entrepreneur) responsable de chaque étape du processus. Cependant, les étapes fondamentales du processus d’ingénierie des systèmes (concept d’opération, exigences, conception, etc.) devront encore être franchies pour tous les types d’approvisionnement des STI.

Comme il a été mentionné plus tôt dans la présente section, l’ingénierie des systèmes est une approche systématique visant à définir, à concevoir et à valider des systèmes qui répondent pleinement aux besoins de leurs utilisateurs. Une approche complète en matière d’ingénierie des systèmes est également axée sur la planification, la gestion des risques, la gestion de la configuration et d’autres processus. Chaque promoteur de projet de STI utilise une approche en matière d’ingénierie des systèmes qu’il peut adapter en fonction des besoins de son projet. Les analyses d’ingénierie des systèmes requises deviennent des étapes « requises » qui ne peuvent pas être adaptées.

7.3.3 Utilisation de l’architecture pour soutenir l’ingénierie des systèmes

Les sections 7.3.4 à 7.3.7 portent sur les possibilités d’utiliser l’information contenue dans une architecture régionale des STI pour soutenir les étapes du processus d’ingénierie des systèmes. Chacune de ces possibilités est décrite dans le cadre du processus d’élaboration de projets.

Avant que l’architecture régionale des STI puisse être utilisée, la partie de l’architecture relative au projet doit être définie. Le processus d’établissement du sous-ensemble de l’architecture est décrit à la section 7.3.4. Une fois que cette portion est définie, les composantes pertinentes peuvent être utilisées afin de soutenir le processus d’ingénierie des systèmes. L’utilisation potentielle de l’architecture régionale des STI pour soutenir chacune des étapes est présentée aux sections 7.3.5, 7.3.6 et 7.3.7.

Étant toutes différentes, les architectures régionales des STI n’apportent pas le même soutien au processus d’ingénierie des systèmes. Par exemple, les architectures qui contiennent des exigences fonctionnelles adaptées constitueront un meilleur point de départ pour la définition des exigences relatives aux systèmes des projets que les architectures ayant moins d’exigences génériques. La région pourrait examiner sans détours l’utilité de son architecture dans le processus de mise en oeuvre des projets, puis l’améliorer au fil du temps de manière à ce qu’elle puisse fournir le meilleur soutien possible au processus d’ingénierie des systèmes de chaque promoteur de projet.

7.3.4 Faire correspondre un projet de STI à l’architecture régionale des STI

Avant d’utiliser l’architecture régionale des STI pour soutenir l’élaboration de projets, la partie de l’architecture qui sera incluse dans le projet doit être définie. Cette étape est essentielle à l’utilisation de l’architecture régionale des STI, car elle coïncide avec le moment où le projet de STI est considéré dans le contexte plus large de l’architecture. La portée initiale du projet est définie lorsque les services, la fonctionnalité et les possibilités d’intégration envisagés dans la région sont examinés. Mis ensemble, les volets qui suivent définissent précisément la portée du projet en fonction de l’architecture régionale des STI :

• les composants de l’inventaire;
• les exigences fonctionnelles;
• le flux d’information.

Ces trois volets définissent le ou les systèmes qui seront créés par le projet ou qui en résulteront, la fonctionnalité qui sera mise en place, ainsi que les interfaces qui seront ajoutées ou mises à jour.

Si des possibilités d’intégration devaient être prises en considération, l’architecture régionale des STI devrait être utilisée le plus tôt possible dans le cycle de vie de l’élaboration des projets. L’architecture devrait être examinée avant que les coûts des projets soient évalués, alors que la possibilité existe toujours de modifier leur portée pour tenir compte de la fonctionnalité et des interfaces établies dans l’architecture. Cette possibilité pourrait survenir avant ou après la programmation ou l’établissement d’un budget, tout dépendant de la manière particulière dont le projet de STI est défini.

Trouver les volets appropriés

Il est parfois difficile de trouver les volets qui s’appliquent à un projet donné, à plus forte raison si l’équipe du projet ne connaît pas bien l’architecture régionale des STI. Le meilleur moyen de déterminer la partie de l’architecture régionale des STI qui sera incluse dans le projet variera, puisque toutes les architectures régionales sont définies de manière quelque peu différente. Il existe quelques points d’entrée logiques dans l’architecture régionale des STI qui pourraient être utiles à l’équipe de projet. Il y a de fortes chances qu’un de ces volets fonctionne mieux qu’un autre dans votre région.

Commencer par les services de transport
Les services de transport, qui sont habituellement représentés en tant qu’ensembles de solutions applicatives, sont une excellente façon d’isoler la partie de l’architecture régionale des STI qui peut s’appliquer à un projet de STI. En établissant le service que le projet exécutera et en trouvant ce service dans la liste des ensembles de solutions applicatives inclus dans l’architecture, vous pourrez déterminer quelle partie de l’architecture est associée à ce service, puis l’adapter à votre projet. À noter que, dans la plupart des cas, l’ensemble de solutions applicatives devra être remanié pour pouvoir correspondre exactement à la portée du projet.

Commencer par le séquençage des projets
L’interrelation entre l’architecture régionale des STI et les projets de STI est plus claire, si le projet qui doit être mis en oeuvre est défini explicitement dans la partie relative au séquençage des projets de la documentation sur l’architecture régionale des STI. Si tel est le cas, il s’agit probablement du meilleur point d’entrée dans l’architecture que votre équipe du projet puisse avoir. En revanche, si votre projet n’est pas défini dans la partie relative au séquençage des projets de la documentation sur l’architecture régionale des STI, vous devriez en aviser le propriétaire de l’architecture. Il pourra ainsi mettre à jour son architecture pour qu’elle puisse refléter l’éventail des projets qui sont mis en oeuvre présentement dans votre région.

Autres points de départ
D’après la documentation sur l’architecture, l’équipe du projet pourrait localiser le ou les systèmes cibles dans la liste des composants de l’inventaire ou repérer dans la liste des intervenants celui ou ceux qui sont au projet. Tout dépendant des liens inclus dans la documentation sur l’architecture, un de ces points d’entrée peut être utilisé pour trouver la partie de l’architecture régionale des STI qui est la plus pertinente en regard du projet qui doit être mis en oeuvre.

Envisager d’autres possibilités d’intégration

Dans presque tous les cas, l’architecture régionale des STI déterminera des possibilités d’intégration qui ne seront pas incluses dans le projet actuel. De fait, des possibilités d’intégration pourraient être différées pour de nombreuses raisons, dont celles-ci : deux organismes ou plus interreliés par l’interface ne sont pas prêts; le financement ou le temps disponible n’est pas suffisant pour tout mettre en oeuvre; l’infrastructure de soutien n’est pas encore achevée; une norme d’une importance cruciale n’est pas encore disponible; la mise en oeuvre de beaucoup de choses à la fois est beaucoup trop complexe ou comporte trop de risques, etc.

Il est important d’explorer ces possibilités d’intégration pour qu’elles puissent soutenir la conception du projet, même si elles peuvent ne pas être mises en place dans le cadre de ce projet en particulier. Le but ultime recherché est de rendre le déploiement des STI aussi économique que possible en examinant comment le projet soutiendra d’autres projets au fil des ans. À cette fin, les possibilités d’intégration future qui pourraient influer sur la conception du projet devraient être déterminées et examinées durant le processus d’élaboration du projet. Par exemple, d’autres intervenants pourraient participer au projet actuel pour s’assurer que les exigences futures seront non seulement établies, mais aussi intégrées à la conception même du projet.

7.3.5 Utilisation de l’architecture dans l’élaboration du concept d’opération

Une architecture régionale des STI bien définie fournit un bon point de départ pour l’élaboration du concept d’opération (CONOP) d’un projet de STI. Le but d’un CONOP est de transmettre clairement une vue d’ensemble de niveau élevé du projet que chaque intervenant peut comprendre. Les éléments de l’architecture fournissent une description de niveau élevé des STI dans la région, qui peuvent être directement incorporés au CONOP d’un projet. Divers éléments ou volets de l’architecture peuvent être utilisés, comme le montre la Figure 26, qui relie l’architecture régionale des STI aux grandes lignes typiques d’un concept d’opération à partir de la norme industrielle ANSI/AIAA G-043-1992. Le CONOP élaboré pour un projet de STI devrait inclure ces données et plusieurs autres particulières au projet, comme l’expliquent les paragraphes qui suivent.

Repérage des intervenants

Un concept d’opération devrait décrire les STI à partir de la perspective de chaque intervenant. Les intervenants mentionnés dans l’architecture régionale des STI représentent un bon point de départ pour la préparation de la liste des intervenants que le CONOP prend en considération. L’équipe du projet pourrait ajouter des noms d’intervenants à la liste ou une spécificité en rapport avec les intervenants choisis.

Concept d’exploitation

Les rôles et les responsabilités de l’organisme, qui sont précisés dans le CONOP peuvent provenir du concept d’exploitation contenu dans l’architecture régionale des STI. Ainsi, le concept d’exploitation peut servir de point de départ pour une définition plus détaillée des rôles opérationnels décrits dans le CONOP d’un projet de STI.

Exigences fonctionnelles

Les exigences fonctionnelles contenues dans l’architecture régionale des STI (de niveau élevé) sont définies à un niveau qui correspond aux besoins opérationnels qui devraient être définis dans le CONOP. Les besoins opérationnels définis dans le CONOP fournissent ensuite une base aux exigences relatives à un projet de STI qui seront définies plus tard dans le processus d’ingénierie des systèmes. Les exigences de niveau élevé provenant de l’architecture régionale des STI peuvent être incluses dans le CONOP et modifiées, au besoin, pour correspondre aux besoins opérationnels d’un projet donné.

Interfaces / flux d’information

Le CONOP contient une description de niveau élevé du projet qui est généralement soutenu par un schéma fonctionnel des systèmes de niveau élevé. Cette description des systèmes peut reposer sur les interfaces et les flux d’information issus de l’architecture régionale des STI. Tout dépendant de l’architecture régionale des STI et de la nature du projet, la description du projet provenant de l’architecture devrait être améliorée pour qu’il soit le plus possible facile de comprendre son inclusion dans le CONOP.

La relation de chaque projet avec l’architecture régionale des STI (voir la section 7.3.3) devrait être incluse dans le concept d’opération. Si la norme ANSI/AIAA est utilisée aux fins du CONOP, cette information devrait logiquement correspondre au paragraphe « Environnement opérationnel », ou la norme pourrait être adaptée et un paragraphe intitulé « Rapport avec l’architecture régionale des STI » pourrait être ajouté.

Ententes

L’intégration des systèmes est davantage un défi institutionnel qu’un exercice technique de l’ingénierie des systèmes. L’architecture régionale des STI établit des ententes régionales qui peuvent être pertinentes à un projet de STI. Les ententes nécessaires devraient être établies aux fins du projet et incluses soit dans le plan du projet, soit dans le CONOP. Si la norme ANSI/AIAA est utilisée, la liste des ententes devrait logiquement correspondre à la section « Environnement opérationnel » ou « Environnement de soutien ». L’emplacement de la liste des ententes n’est pas important dans la mesure où elle est incluse dans le document et où le plan du projet aborde la création des ententes nécessaires. Si des ententes nécessaires ne sont pas représentées dans l’architecture, l’organisation responsable de l’entretien de l’architecture devrait en être informée.

7.3.6 Utilisation de l’architecture dans l’établissement des exigences fonctionnelles

Les exigences fonctionnelles et les interfaces définies dans l’architecture régionale des STI peuvent soutenir la définition des exigences relatives aux systèmes du projet. Les exigences fonctionnelles associées aux composants de l’inventaire inclus dans le projet peuvent être analysées pour établir les exigences relatives à la fonctionnalité requise aux fins du projet. Ces exigences fonctionnelles peuvent constituer un des intrants à la définition des exigences relatives aux systèmes. En outre, chaque interface du projet établie dans l’architecture régionale des STI devrait aussi être soutenue par les exigences relatives aux systèmes qui lui sont associées.

Bien entendu, les exigences relatives aux systèmes du projet devraient être définies de manière plus détaillée que les exigences fonctionnelles de niveau élevé contenues dans l’architecture régionale des STI. Les exigences relatives aux systèmes devraient aussi porter sur le rendement, l’élaboration, l’exploitation et l’entretien, ainsi que sur d’autres exigences qui ne sont pas généralement incluses dans une architecture régionale des STI, comme le montre la Figure 27. Bien que les exigences incluses dans l’architecture régionale des STI soient seulement un point de départ, il vaut mieux commencer par ces exigences que de partir de rien. En commençant par les exigences relatives à l’architecture régionale des STI, l’équipe du projet dispose d’un bon point de départ et maintient la continuité entre l’architecture et les projets de la région.

Les exigences fonctionnelles associées au projet peuvent être extraites. Chaque exigence relative à l’architecture régionale des STI peut se traduire en des exigences fonctionnelles plus détaillées. Par exemple, une exigence simple visant à contrôler des panneaux à messages variables pourrait être une exigence de niveau élevé qui se traduit par de nombreuses exigences relatives à la définition des messages, à la gestion des messages, à leur affichage, à leur ordonnancement et à leur priorisation.

7.3.7 Utilisation de l’architecture dans la conception des projets

L’architecture régionale des STI peut être utilisée par les concepteurs de projets comme point de départ d’une conception de niveau élevée des projets et pour établir les normes STI qui pourraient s’appliquer au projet

Le sous-ensemble de l’architecture régionale des STI dont il est question à la sous-section 7.3.3 forme la base de la conception de niveau élevé ou architecturale aux fins du projet. Ce sous-ensemble devrait établir les principales interfaces interorganismes (le cas échéant) que le projet doit soutenir, de même que les principales interfaces des systèmes. La conception architecturale du projet ajoute alors des renseignements importants, mais ramène la traçabilité au cadre de travail de l’architecture. Lors de la conception architecturale d’un projet qui correspond à l’architecture régionale des STI, il y a une traçabilité tout au long du processus, de la planification à la mise en oeuvre.

L’architecture régionale des STI inclut une correspondance à des normes STI qui peuvent être utilisées pour établir les normes STI applicables au projet. Les normes établies dans l’architecture sont uniquement un point de départ pour la spécification de la conception du projet. Habituellement, seulement un sous-ensemble de normes établies est utilisé dans le projet. L’information importante doit être contenue dans la spécification afin de déterminer quelles sont les parties de la norme pertinentes à l’approvisionnement particulier.

Certaines régions créent un plan de normes qu’elles intègrent à leur architecture. Un tel plan définit l’approche visant à incorporer les normes aux projets de STI au fil du temps. S’il existe, le plan de normes doit être consulté lors de la mise en oeuvre des normes. Si le plan ne reflète pas adéquatement l’utilisation préférée des normes, l’organisation responsable de l’entretien de l’architecture régionale des STI devrait en être informée. La section 6.3.3 décrit les plans de normes STI plus en détail.

7.3.8 Rétroaction fournie à l’organisation responsable de l’entretien de l’architecture

Les équipes de projets qui utilisent l’architecture régionale des STI seront une des sources les plus importantes des changements apportés à l’entretien de l’architecture. À mesure que les projets sont mis en oeuvre, ils seront mis en correspondance avec l’architecture, et une partie importante de l’architecture sera examinée minutieusement durant le processus. Chaque région devrait définir un mécanisme permettant à chaque équipe de projet de fournir des commentaires sur l’architecture en y consacrant le moins de temps possible. Beaucoup d’éléments de l’architecture régionale des STI peuvent être améliorés au moyen de la rétroaction au sujet de l’utilisation de l’architecture. Comme nous l’avons vu à la section 7.3.1, un point de contrôle dans le processus devrait être établi au moment où une équipe examine la conception de son projet conforme à l’exécution et où elle soumet des commentaires au sujet de l’architecture régionale des STI, de la même manière que des plans conformes à l’exécution sont soumis dans le cadre de projets de construction traditionnels.

Quelques mesures clés peuvent être prises pour mettre en place un processus de rétroaction adéquat relativement à l’architecture régionale des STI et, en dernier ressort, pour améliorer la qualité de l’architecture. D’une part, le processus doit être assez rigoureux pour que la rétroaction ne soit pas négligée dans l’empressement d’achever le projet. D’autre part, des pratiques exemplaires en matière de gestion de la configuration sont nécessaires, à l’équipe du projet aussi bien qu’à l’organisation responsable de l’entretien de l’architecture, pour que les modifications requises soient définies, comptabilisées et incorporées au fil du temps. La section 8 présente en détail l’entretien de l’architecture régionale des STI.

---

 

 

[ Précédente : Chapitre 6 ]

[ Suivante : Chapitre 8 ]