Architecture de Solutions (TEMPLATE)

Architecture de solution
NOM DU CLIENT
NOM DU PROJET
NOM DU CLIENT
NOM DU PROJET
VERSION 1.0.0
Table des matières

1 Aperçu______________________________________________________________________5
1.1 OBJECTIF___________________________________________________________________5
1.2 PORTÉE DU DOCUMENT_______________________________________________________5
2 Description du projet__________________________________________________________6
2.1 APERÇU DU PROJET_________________________________________________________6
2.2 PORTÉE____________________________________________________________________6
2.3 OBJECTIFS D’ARCHITECTURE_________________________________________________7
2.4 HYPOTHÈSES ET CONTRAINTES DE L’ARCHITECTURE____________________________7
2.5 APERÇU DE LA SOLUTION_____________________________________________________8
3 Vue Logique_________________________________________________________________9
4 Implémentation______________________________________________________________10
4.1 PORTÉE___________________________________________________________________10
4.2 INTÉGRATION______________________________________________________________10
4.2.1 LISTE______________________________________________________________________11
4.2.2 MÉTHODE D’INTÉGRATION___________________________________________________12
4.2.2.1 [TITRE DE LA MÉTHODE 1]____________________________________________________12
4.2.2.2 [TITRE DE LA MÉTHODE 2]____________________________________________________12
4.2.2.3 WSO2_____________________________________________________________________13
4.2.2.4 SDK_______________________________________________________________________13
5 Conception_________________________________________________________________14
5.1 [DESIGN 1]_________________________________________________________________14
5.2 [DESIGN 2 – EXEMPLE : CATALOGUE]__________________________________________14
5.2.1 [SOUS-PARTIE 1 DU DESIGN - EXEMPLE: CATALOG VIEW]_________________________14
5.2.2 [SOUS-PARTIE 2 DU DESIGN - EXEMPLE: CATÉGORISATION]______________________14
5.3 [DESIGN 3]_________________________________________________________________15
5.4 [DESIGN 4]_________________________________________________________________15
5.5 [DESIGN 5]_________________________________________________________________15
6 Vue de déploiement__________________________________________________________16
7 Autres considération_________________________________________________________17
7.1 SÉCURITÉ__________________________________________________________________17
7.1.1 AUTHENTICATION & AUTHORISATION__________________________________________17
7.1.2 SERVICES__________________________________________________________________17
7.1.3 ACCÈS À DISTANCE_________________________________________________________17
7.1.4 PCI COMPLIANCE___________________________________________________________17
7.2 AUDITING__________________________________________________________________17
NOM DU CLIENT
NOM DU PROJET
7.3 SEO_______________________________________________________________________17
7.4 WEB ANALYTICS____________________________________________________________17
7.5 INTERNATIONALISATION_____________________________________________________18
8 Haute disponibilité___________________________________________________________19
8.1 DATA CENTERS_____________________________________________________________19
8.2 DISASTER RECOVERY_______________________________________________________19
9 Scalability__________________________________________________________________20
9.1 LOAD BALANCING__________________________________________________________20
9.2 CACHING__________________________________________________________________20
9.3 MONITORING_______________________________________________________________20
cgi.com
Architecture de Solution – Présenté à [NOM DU CLIENT]. © 2023 GROUPE CGI INC. 3
NOM DU CLIENT
NOM DU PROJET
Historique des révisions

Version Date Auteur Description
0.1 2023-06-08 Nom de l’auteur du document Création du document
0.2 2023-06-09 Nom du réviseur du document Commentaire sur la révision ou l’ajout de contenu
1.0 2023-06-10 Nom du réviseur du document Livraison du document complété
1.1 2023-06-11 Nom du réviseur du document Version corrigée
cgi.com
NOM DU CLIENT
NOM DU PROJET
1 Aperçu
1.1 Objectif
Le présent document introduit l’architecture de [DESCRIPTION DU PROJET]. Il spécifiera comment [ICI
DÉCRIRE LE BUT DU PROJET].
1.2 Portée du document

La portée de ce document est de couvrir les aspects de conception et l’architecture technique de la solution
utilisée et personnalisé dans le cadre du projet [NOM DU PROJET + NOM DU CLIENT]. Ce document est
évolutif et pourra être mis à jour tout au long du projet pendant la réalisation des sprints.
cgi.com
NOM DU CLIENT
NOM DU PROJET
2 Description du projet
2.1 Aperçu du projet
[DESCRIPTION DU PROJET]
2.2 Portée
[Portée du travail de CGI sur le projet et la portée de cette documentation d’architecture]
cgi.com
NOM DU CLIENT
NOM DU PROJET
2.3 Objectifs d’Architecture
Les grands objectifs de l’architecture sont motivés par ces requis :

 REQUIS 1 (haut niveau);
 REQUIS X.
2.4 Hypothèses et contraintes de l’architecture

 HYPOTHÈSE 1;
 HYPOTHÈSE 2;
 HYPOTHÈSE X.
cgi.com
NOM DU CLIENT
NOM DU PROJET
2.5 Aperçu de la Solution

EXEMPLE :
La solution « X» sera déployée dans Azure; CGI effectuera les « extensions » requises en suivant les bonnes
pratiques et principes [NOM DE TECHNO/PLATEFORMES APPLICATIVES/…]. Les environnements seront
créés par [PARTENAIRE ou CGI] et CGI sera responsable de déployer les composantes dans les
environnements appropriés selon les bonnes pratiques de [PARTENAIRE] en utilisant les outils de Continous
Integration (CI) déployés par [PARTENAIRE]. CGI modifiera les scripts de déploiement pour inclure les
personnalisations requises. L’architecture de la solution en mode SAAS est dictée par [PARTENAIRE], celle-ci se
divise en plusieurs tiers :
A) La couche de présentation : CGI utilisera l’application de référence fournis par [PARTENAIRE]. Le
« blueprint » [PARTENAIRE] sera utilisé pour la construction du site Web avec les ajustements requis
pour représenter les bannières et les particularités des lignes de produits. Un template par « page » et
ligne de produit sera créé.
B) Les objects métiers/composants et modules : (NOM DE L’APPLICATION) sera utilisé pour « construire
l’application Web»; Les modules [PARTENAIRE] sont développés en Java, CGI créera les extensions sur
les composantes requises pour répondre aux requis fonctionnels.
C) Connecteurs : Le « [NOM DE L’API DU PARTENAIRE] » du [PARTENAIRE] permet à plateforme [NOM
DE LA PLATEFORME] de se connecter vers des systèmes patrimoniaux; CGI développera les
connecteurs requis selon ce framework pour s’intégrer avec les systèmes identifiés.
D) Parties Tierces : Des solutions « Native » tel que NetBanx, GoogleMap seront utilisés dans la solution;
Pour ces solutions, les intégrations seront faites utilisant les API propriétaires à chaque solution, soit en
passant par un connecteur ou directement, selon la méthode la plus approprié.
E) Systèmes patimoniaux : La solution doit s’intégré avec les systèmes existants du [NOM DU CLIENT]
(identifiés dans le tableau 2-1 : Intégration). Toute les intégrations synchrones avec ces systèmes seront
faites, tel que requis, par Rest (Resful) services en utilisant le « ServiceBus » WSO2 déployé par [NOM
DU CLIENT]. Les échanges en différé (asynchrones) se feront par fichier dans les formats imposés par
[PARTENAIRE], le WSO2 du [NOM DU CLIENT] enverra les fichiers dans l’environnement du
[PARTENAIRE] (Blob Azure).
cgi.com
NOM DU CLIENT
NOM DU PROJET
3 Vue Logique
Ce diagramme représente les principales composantes logicielles ainsi que leurs objets métiers
{ici ajouter diagramme et indiquer en dessous les divers parties du diagrammmes – voir exemple ci-dessous}
 [PARTENAIRE] : Plateforme de [TYPE DE PLATEFORME] (SAAS)

 [NOM DU CRM] : CRM
 [NOM DU ERP] : ERP de [NOM DU CLIENT]
 [NOM DE BD] : Base de données centralisée des informations client
cgi.com
NOM DU CLIENT
NOM DU PROJET
4 Implémentation
4.1 Portée
{ Diagramme de la solution plus détaillé }
Figure 4-1 Solution
Composante Description
Azure Microsoft Azure Cloud Computing Service
[PARTENAIRE] [description de la plateforme SAAS]
WSO2 Gateway Open source
Partie Tierce Autres Progiciel/plateforme utilisé par [NOM
DU CLIENT]
 Intégration : L’utilisation « native » de la plateforme sera effectuée et les services passerons soit par
services REST ou par échange de fichier.
 Personnalisation : Les composantes [PARTENAIRE] seront étendues pour répondre aux besoins.
 Hors Périmètre : aucune modification ne sera apportée par CGI pour ces composantes.
4.2 Intégration
{Diagramme des interactions entre les divers composants}

Figure 4-2 : Intégration
 Les intégrations avec les systèmes du [NOM DU CLIENT] passeront toutes par le service BUS WSO2;
 L’échange de fichier entre [NOM DU CLIENT] et Azure se fera par SFTP, ce service est offert par
[PARTENAIRE];
 Les intégrations avec WSO2 sont faites par REST(Restful) services;
 La mise à jour des clients se fera par un mécanisme de « publish/subscribe » (Interne à WSO).
[PARTENAIRE] expose un service REST du client pour la mise à jour du client et enverra un message
(service REST) à WSO2 suite à une mise à jour du client.
cgi.com
NOM DU CLIENT
NOM DU PROJET
4.2.1 LISTE
Thème Solution Ref. requis Hypothèse Intrant Extrant Complexité
Import de Intégration Import-1 Le [NOM DU [PARTENAIRE] [NOM DU [simple,
produits par fichier CLIENT] va fournir CLIENT] medium,
un fichier pour … complexe]
Import de Intégration Import-2 [description avec WSO2 [PARTENAIRE]
client par web extrant et intrant]
service
Paiement NetBanx Facturation-2 [description avec NetBanx [PARTENAIRE]
par carte Intégration-3 extrant et intrant]
de crédit
Tableau 2-1 : Intégration
cgi.com
NOM DU CLIENT
NOM DU PROJET
4.2.2 MÉTHODE D’INTÉGRATION
4.2.2.1 [TITRE DE LA MÉTHODE 1]
{exemple ci-dessous}
Les imports utiliseront les formats « natif » de [PARTENAIRE]. La transformation de données se fera en amont
(dans Spring Batch).
Spring Batch communiquera l’information via SFTP à [PARTENAIRE] qui intégrera le fichier depuis le SFTP à une
cédule définie
Import Description Cédule
[journalier, hebdo, chaque heure,

Produit Liste des produits à créer/modifier
…]

Produit Assignation attributs spécifique
…]

Prix Assignation des prix par défaut
…]
Assignation des prix de vente en [journalier, hebdo, chaque heure,

Prix
ligne …]
Prix Assignation des prix en solde
Définition des promotions et prix

Promotion N/A (manuelle, par la console)
promotionnels
4.2.2.2 [TITRE DE LA MÉTHODE 2]

[PARTENAIRE] offre plusieurs services REST qui sont exposés. La méthode d’intégration de ces services avec
[NOM DU CLIENT] est l’utilisation native de [PARTENAIRE].
La liste des services offerts est documenté dans Swagger : Services Web de [PARTENAIRE]
La liste des services utilisés dans le cadre de [NOM DU CLIENT/NOM DU PROJET] est la suivante :
Service Description
Get/Customer/{CustomerKey} Get current customer profile details
cgi.com
NOM DU CLIENT
NOM DU PROJET
4.2.2.3 WSO2
WSO2 sera utilisé comme service bus pour toutes communications avec le(s) ERP(s) de [NOM DU CLIENT];
4.2.2.4 SDK
Des SDK seront utilisés pour les parties tierces; L’utilisation de ces SDK est détaillée dans confluence par [NOM
DU CLIENT].
Liste des composantes :
 GoogleMap
 AddThis
 NetBanx
 Poste Canada
 Google shopping
cgi.com
NOM DU CLIENT
NOM DU PROJET
5 Conception
5.1 [DESIGN 1]
{exemple ci-dessous – diagrammes, tableaux et schémas peuvent être ajoutés pour étoffer le design}
[PARTENAIRE] offre plusieurs possibilités pour partager et « organiser » le contenu. Dans le cadre de [NOM DU
CLIENT/NOM DE PROJET], il y aura une seule organisation, chaque « bannière » sera représenté par un
« canal » et aura sa propre application (contenant le CSS et « branding » de base) mais partageant les mêmes
templates; Dans les phases ultérieures, les bannières du groupe Tanguay seront ajoutées à la même
Organisation et auront chacune leur « Canal ».
Cette structure permettra aussi d’incorporer des catalogues fournisseurs (soit dans une autre organisation, ou
autres canaux) ainsi que les magasins (points of sales) dans une stratégie omni commerce.
5.2 [DESIGN 2 – exemple : CATALOGUE]

{exemple ci-dessous}
Le catalogue [PARTENAIRE] est composé de catégories, de produits et de contenu associé au produit.
[PARTENAIRE] permet l’utilisation de plusieurs « Catalog » pour une même organisation, ces catalogues sont
utilisés dans les canaux et hérités dans les applications. Un catalogue est une catégorie « maître » et sera affiché
dans le menu principale.
5.2.1 [SOUS-PARTIE 1 DU DESIGN - EXEMPLE: CATALOG VIEW]

[PARTENAIRE] offre aussi la possibilité d’avoir des « Catalog View », on peut voir ceux-ci comme étant des filtres
sur une recherche de produit. Les « catalog view » seront utilisés pour les catégories tel que « nouveauté » ou
encore « magasinez par pièce ».
5.2.2 [SOUS-PARTIE 2 DU DESIGN - EXEMPLE: CATÉGORISATION]

La catégorisation s’effectuera dynamiquement selon les attributs du produit. Un attribut custom
« Categorie_ERP » sera ajouté sur chaque produit. En utilisant les « Predefined Product Filters » de
[PARTENAIRE], sur les catégories, les produits seront catégorisés automatiquement à l’import dans les bonnes
catégories associées « channels ».
Les « Predefined Product Filters » seront créé par CGI pour l’arborescence de base et pourra être maintenu par
les équipes de développement de [NOM DU CLIENT] par la suite.
Voir {lien vers la documentation}
cgi.com
NOM DU CLIENT
NOM DU PROJET
5.3 [DESIGN 3]
{peut-être une section à documenter dans un prochain sprint}
5.4 [DESIGN 4]
5.5 [DESIGN 5]
cgi.com
NOM DU CLIENT
NOM DU PROJET
6 Vue de déploiement
{diagramme et description}
cgi.com
NOM DU CLIENT
NOM DU PROJET
7 Autres considération
7.1 Sécurité
7.1.1 AUTHENTICATION & AUTHORISATION

Les clients internes de la plateforme (utilisation les consoles [PARTENAIRE]) seront créés dans [PARTENAIRE]
Les clients externes de la plateforme (utilisation les consoles [PARTENAIRE]) seront créés dans [PARTENAIRE]
7.1.2 SERVICES
Les accès aux services seront restreints aux personnes responsables. (Voir ANNEXE A)
7.1.3 ACCÈS À DISTANCE

{exemple avec Putty, Remote desktop, Azure, …}
7.1.4 PCI COMPLIANCE

Il n’y aucun requis spécifique à la conformité PCI (PCI-DSS). Néanmoins, aucun numéro de carte de crédit sera
conservé dans la plateforme de [PARTENAIRE]. La sécurité du paiement sera assurée par le fournisseur de ce
service (NetBanx).
7.2 Auditing
{à compléter}
7.3 SEO
Les items suivant doivent être pris en compte pour le SEO sur une plateforme de commerce électronique
 Pour toutes les pages : keywords et meta-data seront contribués dans la console de [PARTENAIRE] dans
les données de catégories, de produits et de contenu CMS. Cette contribution sera effectuée au niveau
des canaux
 Pour les “Crawlers”, le(s) sitemap(s) sera généré par le système à partir des données du catalogue et
CMS. Le fichier robots.txt sera géré manuellement.
 Les « Friendly URL » seront déterminé par une « personnalisation » des composantes [PARTENAIRE]
pour les pages de produit et catégories, pour les pages de contenu, [PARTENAIRE] permet de mettre
l’URL voulu.
 URL redirection (si requis) sera géré par les composantes [PARTENAIRE] (contribution)
7.4 Web analytics
cgi.com
NOM DU CLIENT
NOM DU PROJET
Tel que requis par [NOM DU CLIENT] Google Tag Manager sera utilisé pour en tant qu’outils d’analytic. Les
fragments JavaScript requis seront intégrés dans les composantes requise du CMS. La stratégie d’ analytics sera
la même que dans le système existant.
7.5 Internationalisation
Les services de [PARTENAIRE] seront utilisés.
cgi.com
NOM DU CLIENT
NOM DU PROJET
8 Haute disponibilité
Tel que dans le contrat de service de [PARTENAIRE].
8.1 Data Centers

Les données seront hébergées dans le cloud Microsoft Azure dans la zone Canada Est
8.2 Disaster Recovery

Tel que dans le contrat de service de [PARTENAIRE].
cgi.com
NOM DU CLIENT
NOM DU PROJET
9 Scalability
La solution et les outils sont fournis par [PARTENAIRE].
9.1 Load balancing
9.2 Caching
9.3 Monitoring
cgi.com
NOM DU CLIENT
NOM DU PROJET
Annexes
cgi.com
NOM DU CLIENT
NOM DU PROJET
Annexe A – {si nécessaire}

Diagramme, documentation, norme, …
cgi.com
cgi.com

Architecture de Solutions (TEMPLATE)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Architecture de Solutions (TEMPLATE)

Transféré par

Droits d'auteur :

Formats disponibles

Architecture de solution

Table des matières

Historique des révisions

1.2 Portée du document

2.3 Objectifs d’Architecture

Les grands objectifs de l’architecture sont motivés par ces requis :

2.4 Hypothèses et contraintes de l’architecture

2.5 Aperçu de la Solution

 [PARTENAIRE] : Plateforme de [TYPE DE PLATEFORME] (SAAS)

Figure 4-1 Solution

{Diagramme des interactions entre les divers composants}

Tableau 2-1 : Intégration

4.2.2 MÉTHODE D’INTÉGRATION

4.2.2.1 [TITRE DE LA MÉTHODE 1]

Import Description Cédule

[journalier, hebdo, chaque heure,

[journalier, hebdo, chaque heure,

[journalier, hebdo, chaque heure,

Assignation des prix de vente en [journalier, hebdo, chaque heure,

Prix Assignation des prix en solde

Définition des promotions et prix

4.2.2.2 [TITRE DE LA MÉTHODE 2]

Get/Customer/{CustomerKey} Get current customer profile details

5.2 [DESIGN 2 – exemple : CATALOGUE]

5.2.1 [SOUS-PARTIE 1 DU DESIGN - EXEMPLE: CATALOG VIEW]

5.2.2 [SOUS-PARTIE 2 DU DESIGN - EXEMPLE: CATÉGORISATION]

{peut-être une section à documenter dans un prochain sprint}

7.1.1 AUTHENTICATION & AUTHORISATION

7.1.3 ACCÈS À DISTANCE

7.1.4 PCI COMPLIANCE

7.4 Web analytics

8.1 Data Centers

8.2 Disaster Recovery

9.1 Load balancing

Annexe A – {si nécessaire}

Vous aimerez peut-être aussi