CONCEPTION DE L’ACHITECTURE D’UN SYSTEME

INTRODUCTION :
Le projet qui nous a été donner consiste à créer une application web et mobile font-end et
backend pour la gestion des activités parascolaire. Dans le cadre de notre projet nous allons
commencer par la conception de l’architecture de notre système. La conception d’une
architecture système est fait par un architecte.

Découvrir le métier d’architecte

Un architecte en un mot est celui qui est dépositeur d’une méthode et d’une vision (une
vision qui devra défendre avec la méthode choisi).
La méthode permet d’analyser un système sellons tous les axes et surtout de poser
les bonnes questions. Notre méthode consistait à se poser la bonne question a nous
et à l’usage de l’application à concevoir, les questions poser était comme suite :
1. En tant que bonne architecte la question qui est toujours poser en premier
est de savoir ce que on veut faire ?
2. Pourquoi on veut concevoir ?
3. Quel sont les attend que l’usage attende de nous ?
4. Qu’est le budget ?
5. De combien de temps disposons nous ?
6. Y a t’il déjà une application existante ou devons-nous en construire un
nouveau.
La vision est le fruit d’une réflexion en commun entre les experts des diffèrent
composants entre eux afin d’en obtenir la Meilleur efficacité globale (qui est notre
architecture cible).

Plus un architecte est expérimenté, plus il est à même d’appliquer la méthode de façons
pertinente, en posant des question plus précise et parfois plus intrusive, dans le but
d’orienter la réflexion ou même de partager la propre réflexion à l’interlocuteur.

Les qualités attendu d’un architecte et comment progresser

 La posture d’un architecte s’acquière au fil du temps. Donc la meilleure façon de
progresser pour un architecte peux expérimenter dit architecte Junior est
d’apprendre et ce fait encadre par un architecte plus expérimenté dit architecte
Senior.
 Un architecte confirme doit avoir un profile n T. la barre verticale pour expertise et
l’horizontale pour variété.
  Une communication sans faille est absolument indispensable aussi bien à l’écrit qu’a
l’oral.
 Les documents produire doivent être claires et synthétiques et server de base
d’échange et de réflexions. A l’oral, c’est la force de conviction qui fait la différence,
permettent de defender et d’expliquer ses choix, et surtout de porter la vision qui est
au centre du métier.

Les caractéristiques d’une bonne architecture.

Les caractéristiques d’une bonne architecture sont : SECURITE, ELASTICITE, PERFOEMANCE,
COUPLAGE FAIBLE, SIMPLICITE.

LA SECURITE
C’est l’une des premières questions à poser et à se poser : Comment sécuriser mon
application, mon infrastructure ? Pour la sécurisation de notre système on peut
s’accrocher sur l’acronyme DICT (DISPONIBILITE INTEGRITE CONFIDENTIALITE
TRACABILITE) ainsi que PDMA (Perte de Donnée Maximum Admissible).
Détaillons alors ce qu’implique chaque terme de la DICT puis la PDMA

I. Disponibilité
C’est le reflet de la capacité d’une application à être résiliente à tout
événement pouvant générer un arrêt de service. Elle doit répondre aux
exigences exprimées par le demandeur : combien de temps peut-on s’arrêter
en cas de sinistre.

II. Intégrité
Il s’agit de s’assurer qu’une donnée n’est pas modifiée, encore une fois le plus
souvent dans un cadre sensible ou légal. Par exemple comme dans le cadre de
notre projet on doit s’assure que seuls les administrateurs on accès a la base
de données, et de la modifie.

III. Confidentialité
Ici il s’agit de protéger des données sensibles au public. La plupart des
entreprises dispose d’une classification de la sensibilité de leurs données, en
fonction de l’impact de leur publication. On peut distinguer deux types de
données confidentielles : celles très sensibles qui touchent au métier de
l’entreprise et dégraderaient sa capacité à continuer son activité en cas de
fuite ou de corruption et celles, réglementaires, qui légalement doivent être
protégées, gardées secrètes ou supprimées (on pense à la RGPD,
notamment). Par exemple un utilisateur ne doit pas pouvoir télécharger le
code source de notre application pour le vendre
 IV. Traçabilité
C’est la capacité à garder une preuve de l’accès ou de la modification d’une
donnée, dans le temps. Cette notion est particulièrement pertinente pour les
données réglementées ou celles, souvent confidentielles, qui ne doivent être
consultées que par peu de personnes. Par exemple nous devons prendre note
de qui a modifié l’image de fond de notre application et quand.

PDMA – La Perte de Données Maximale Admissible

Sous ce nom barbare se cache le dernier pan de la sécurité dans l’architecture,
c’est l’existence même de la donnée qu’il faut pouvoir assurer. En effet, les cas
de corruption et surtout de suppression accidentelle sont assez courants et nécessitent
d’être envisagés en amont lors de la conception d’un système.
Afin de mitiger ces risques, on s’appuie en général sur des mécanismes
de réplication, de sauvegarde et d’externalisation des données. A noter, seule la politique
de sauvegarde permet d’assurer réellement une PDMA.

V. L’élasticité
Composante majeure des architectures modernes, l’élasticité (aussi
appelée scalabilité en bon franglais) est la capacité d’un système à répondre à
des contraintes changeantes. On distingue en général deux types d’élasticité :
une « verticale » dans laquelle on ajoute des ressources supplémentaires aux
éléments existants (plus de processeurs, plus de mémoire, plus de disques…),
l’autre « horizontale » où l’on ajoute de nouveaux éléments (un serveur web
supplémentaire, un switch additionnel).

VI. Le couplage lâche

Le couplage est la nature de l’adhérence qu’ont deux systèmes entre eux. Une
architecture moderne et bien pensée doit permettre une adhérence faible
avec ses interfaces externes (les autres applications utilisées) et internes (ses
propres services, par exemple sa base de données). Par exemple il suffit pour
nous de d’avoir une copie externe des données sur un serveur au cas où une
machine tombe en panne.

VII. La simplicité
La simplicité est une valeur forte de ma conception de l’architecture : un
système simple sera par essence compréhensible donc opérable, extensible et
stable dans la durée.
 Dessinez Notre architecture pour bien la représenter

Comment représenter une architecture ?

Le premier réflexe a adopté quand vous voulez décrire une architecture est de vous appuyer
sur ce qui a déjà été produit : y a-t-il une représentation normée dans l’entreprise au niveau
des icônes ? De l’outillage ? Des codes couleur ? Des outils tels que Microsoft Visio pour les
schémas et Microsoft Powerpoint pour les descriptions et les échanges. Les outils potentiels
sont nombreux mais l'essentiel est de définir un référentiel commun et de l'utiliser !
Un écueil classique est de démarrer sur son logiciel et de commencer à placer les éléments.
Il est conseillé au contraire de démarrer sur papier, où vous ne serez pas gêné par les
contraintes dues aux outils. Une fois une représentation claire dessinée, on peut passer à la
phase logicielle pour la rendre jolie et évolutive.
Afin de se lancer sur une bonne piste, il est bon de toujours se poser la question : « Qu’est-
ce que je souhaite montrer à travers ce schéma ? » Est-ce que ce sont les contraintes de
flux ? Les capacités de reprise ? Les emplacements en datacenter ? On ne pourra jamais tout
représenter sur un même support, il faut donc faire des choix structurants en amont tout en
gardant à l’esprit de privilégier la simplicité.
Que représenter ?
Par défaut, un système d’information vu sous l’angle de l’architecture technique peut se
décomposer en 4 plans :
 Le plan fonctionnel, représente l’aspect métier, c’est à dire ce que fait l’application
et la nature des données qu’elle échange avec le reste du monde ;
 Le plan applicatif est concentré sur l’aspect logiciel : les flux (protocole, fréquence,
sens), les stocks (partage de donnée...), les middlewares (base de données, serveur
java…) et les Framework utilisés (.NET, Java...) ;
 Le plan infrastructure permet de décrire les choix techniques : les serveurs (dans le
cloud ou ailleurs), leur dimensionnement, l’interconnexion via les réseaux, etc. ;
 La couche opérationnelle enfin, décrit comment le système va être géré : les
mécanismes de sauvegarde, de supervision, de métrologie, etc.