Démarche architecture technique d’un SI

1. Démarche architecture technique d’un SI :

1. Exigences d'architecture technique

Concernant la démarche à suivre pour mettre en place une architecture technique, en doit avant tout, se tenir compte de plusieurs conditions auxquelles l’architecture doit répondre. Et que l’on peut cerner dans 8 familles d’exigences :

• Exigences fonctionnelles

• Disponibilité / Fiabilité / plage d’ouverture

• Reprise de service en cas d'incident

• Sécurité (Disponibilité, Intégrité, Confidentialité, Traçabilité)

• Niveaux de performance

• Scalabilité (montée en charge)

• Conservation des données

• Modificabilité (évolutivité)

• Utilisabilité (interaction avec les utilisateurs)

1. Exigences fonctionnelles :

 Il s'agit des fonctionnalités de l'application.

1. Disponibilité / fiabilité / plage d’ouverture : 

La plage d’ouverture du service précise les périodes de temps durant lesquelles l’application doit être active. Par exemple : o 7 j/7, H24 o 7 j/7, H24, hors plage de maintenance le 15 de chaque mois entre 20 h et 6 h o 5 j/7, 9 h-20 h

La disponibilité indique le taux de disponibilité cible de l’application durant les plages d’ouverture. Par exemple : Disponibilité de 99,9 % Des fortes exigences de disponibilité demandent la mise en œuvre d'architecture de Haute disponibilité.

1. Reprise de service en cas d'incident : 

On distingue l'incident local et le désastre site : l'incident est par exemple la perte d'un serveur, tandis que le désastre site est par exemple l'incendie du centre d'exploitation.

Les exigences doivent s'exprimer en RTO et RPO. Le RTO (Recovery Time Objective) est le temps maximum admissible pour reprendre le service. Le RPO (Recovery Point Objective) est la perte maximale de données acceptable après redémarrage. Les objectifs de RPO et le RTO peuvent être différents selon qu'il s'agit d'un incident ou d'un désastre.

1. Sécurité :

Les exigences de sécurité couvrent plusieurs domaines : o Disponibilité o Intégrité o Confidentialité o Traçabilité

1. Performances :

Exigences liées aux éléments suivants :

• Nombres d'utilisateurs,

• Temps de traitement souhaités pour les transactions, les traitements "batchs" (traitement par lots),

• Fréquence des traitements, débit transactionnel, pics de charge, filtre,

• Temps de réponse.

1. Scalabilité :

La scalabilité est la capacité qu’a l’architecture pour évoluer en cas de montée en charge si nécessaire.

• Scalabilité horizontale : possibilité d’ajouter des serveurs d’un type donné. Par exemple : ajout possible de serveurs d'application web avec répartition de charge.

• Scalabilité verticale : possibilité d’upgrader un serveur (ajout de processeurs, RAM, disques…).

1. Conservation des données :

Une application ne peut pas accumuler des données sans limite. Il faut obligatoirement prévoir des mécanismes de purge ou d’archivage. Fixer la durée de l’historique conservé en ligne.

Quand les anciennes données ne doivent plus être conservées en ligne, quelles sont les exigences ? Purge des données ? Transfert des données dans un système d’archivage ? Archivage sur bande magnétique ? Si les données sont archivées sur bande, quel est le temps souhaité maximal pour pouvoir accéder à ces données ?

Prendre en compte les exigences légales :

• Durée de conservation minimale à observer pour certaines données comme les factures.
• Droit à l’oubli : en droit français, on ne peut conserver certaines données nominatives que pendant un temps donné (fixé lors de la demande d'autorisation à la CNIL)

Modificabilité :

Pour les applications sensibles, on traitera le cas des demandes (installation de version correctives, reparamétrage) qui peuvent devoir être faite sans interruption de service (installation et reparamétrage « à chaud »).

Utilisabilité

Exigences concernant des fonctions destinées à améliorer les interactions avec les utilisateurs. Par exemples :

• Cas de traitements longs pour lesquels il est nécessaire de permettre à l’utilisation de visualiser la progression des traitements, de l’interrompre, de le reprendre.