Exigences d'architecture technique
Une architecture physique ou architecture technique est conçue de manière à répondre à des exigences.
Ces exigences recouvrent de nombreuses notions :
- 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
- Modifiabilité (évolutivité)
- Utilisabilité (interaction avec les utilisateurs)
Exigences fonctionnelles[modifier | modifier le code]
Il s'agit des fonctionnalités de l'application.
Disponibilité / fiabilité / plage d’ouverture[modifier | modifier le code]
La plage d’ouverture du service précise les périodes de temps durant lesquelles l’application doit être active.
Par exemple :
- 7 j/7, H24
- 7 j/7, H24, hors plage de maintenance le 15 de chaque mois entre 20 h et 6 h
- 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é.
Reprise de service en cas d'incident[modifier | modifier le code]
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.
Sécurité[modifier | modifier le code]
Les exigences de sécurité couvrent plusieurs domaines:
Performances[modifier | modifier le code]
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,
- filtres,
- temps de réponse.
Scalabilité[modifier | modifier le code]
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…).
Conservation des données[modifier | modifier le code]
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)[1].
- autres exigences.
Modifiabilité[modifier | modifier le code]
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é[modifier | modifier le code]
Exigences concernant des fonctions destinées à améliorer les interactions avec les utilisateurs. 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.
- Cas d’action utilisateur qui est nécessaire de pouvoir annuler (nécessité de pouvoir revenir à un état antérieur cohérent).
- Exploitabilité
Faculté d'exploiter et de superviser le bon fonctionnement de l'application, d'analyser le bon fonctionnement (et le mauvais).
