Dernière modification : 2025-01-07
Date dernière revue globale : <Faire régulièrement des revues complètes de la vue (au moins une fois par an tant que le projet est actif) et mentionner la date ici>
Statut du document : <Donner ici le statut de la vue, par exemple 'DRAFT', 'FINALISÉ',…>
Ceci est la vue applicative du projet. Elle décrit les modules applicatifs en jeu et leurs échanges.
Les autres vues du dossier sont accessibles d’ici.
Le glossaire du projet est disponible ici. Nous ne redéfinirons pas ici les termes fonctionnels ou techniques utilisés.
Mentionner ici les documents d’architecture de référence (mutualisés). Ce dossier ne doit en aucun cas reprendre leur contenu sous peine de devenir rapidement obsolète et inmaintenable.
| N° | Version | Titre/URL du document | Détail |
|---|---|---|---|
1 |
2.0.4 |
XX_Urba_POS.pdf |
POS du SI |
| Sujet | Détail | Statut | Porteur du sujet | Échéance |
|---|---|---|---|---|
Utilisation des services Y |
En fonction de l’avancement du projet Y, ce composant pourrait appeler les services de ce dernier ou ceux de l’ancien composant Z |
EN_ATTENTE |
Projet Y |
AVANT 2040 |
|
Tip
|
Décrire succinctement le projet et en rappeler les objectifs. Mettre en évidence ceux qui sont structurants pour l’architecture. |
Exemple 1 : Cette application doit permettre la dématérialisation des factures reçues de nos fournisseurs et une consultation aisée de ces documents par les services comptables.
Exemple 2 : ce projet est la réécriture en technologies Web de l’application Cobol X. Elle doit en faciliter la maintenance.
Exemple 3: l’ application X est l’un des composants principaux du programme Y. Il s’adosse sur les référentiels Personne et Facturation pour enrichir le CMS en données clients temps réel.
|
Tip
|
Si ce document présente un projet de refonte ou migration, décrire a minima l’application existante. Ne pas reprendre la documentation, y faire simplement référence et pointer vers son éventuel dossier d’architecture. Mentionner néanmoins toute information ayant un impact fort sur la migration ou la conception du nouveau projet. |
Exemple 1 : L’application VENIR2 est une application Client-Server en FORMS 4 pointant vers une base Oracle 9i. Son dossier d’architecture est donné en [REFxyz].
Exemple 2 : L’application existante se base et alimente un annuaire LDAP pour ses autorisations. Le nouveau projet devant fonctionner un temps avec l’ancienne, il convient de prendre en compte les accès concurrents et la cohérence du LDAP pendant la période de tuilage.
|
Tip
|
Si le SI est urbanisé, reprendre le plan d’occupation au sol et préciser le bloc concerné |
|
Tip
|
On entend par ‘internes’ les acteurs appartenant à l’organisation. Il peut s’agir d’humains ou de composants applicatifs. |
| Acteur | Description | Population | Localisation |
|---|---|---|---|
Système de l’administration B |
fournit les données comptables des entreprises |
N/A |
Site de Berlin |
Agent |
Agent back-office |
100 |
Site de Paris |
|
Tip
|
Donner les contraintes budgétaires du projet |
Exemple 1: Enveloppe globale de 1 M€
Exemple 2: Coûts d’infrastructure cloud < 20K€ / mois
|
Tip
|
Sans reprendre dans le détail les plannings du projet, donner les éléments intéressants pour l’architecture. |
Exemple 1: MEP avant fev 2034, prérequis au programme HEAVY en mai 2034.
|
Tip
|
Lister ici les contraintes relatives à l’urbanisation, ceci inclut par exemple mais pas seulement :
|
Exemple 1 : les appels inter-services sont interdits sauf les appels de services à un service de nomenclature.
Exemple 2 : pour en assurer la fraîcheur, il est interdit de répliquer les données du référentiel PERSONNE. Ce dernier devra être interrogé au besoin en synchrone.
Exemple 3 : Lors de la modification d’une commande, les zones comptabilité et facturation seront mises à jour de façon asynchrone via un événement.
Exemple 4 : tous les batchs doivent pouvoir fonctionner en concurrence des IHM sans verrouillage des ressources.
Exemple 5 : les services ne peuvent être appelés directement. Les appels se feront obligatoirement via une route exposée au niveau du bus d’entreprise qui appellera à son tour le service. Il est alors possible de contrôler, prioriser, orchestrer ou piloter les appels.
Exemple 6 : Les composants de cette application suivent l’architecture SOA telle que définie dans le document de référence X.
Exemple 7 : Les composants en zone Internet ne peuvent appeler les composants en zone Intranet pour des raisons de sécurité.
Lister ici (sans détailler) les éventuelles contraintes juridiques liées au projet.
Exemple 1 : Le contrat cadre établi avec l’ESN XYZ prévoit de transférer à notre société les droits patrimoniaux du code source.
Exemple 2 : Le code du projet sera en licence libre et open source GPL V3.
Exemple 3 : Les données produites par le projet seront en licence Ouverte version 2.0.
Exemple 4 : Le CLUF du progiciel prévoit un accès aux sources des utilisateurs ayant des parts dans la société.
|
Tip
|
Donner ici les exigences d’architecture applicative pouvant s’appliquer au projet. En fonction de votre contexte, ne pas hésiter à ajouter des sous-sections. |
|
Tip
|
Décrire ici les exigences en rapport avec la stratégie générale du projet en termes de trajectoire, de budget et d’organisation. |
Exemple 1 : Le développement devra pouvoir se faire au sein d’équipes distribuées, chacune travaillant sur des modules distincts.
Exemple 2 (projet de migration) : Les modules legacy devront faire l’objet d’aussi peu d’adaptations que possible par manque de ressources humaines.
|
Tip
|
Décrire ici les exigences portant sur les protocoles, formats et sémantiques à respecter afin de favoriser les échanges avec des organismes ou tiers. |
Exemple 1: Nos modules XYZ devront pouvoir être exposés aux organismes X depuis Internet et sous la forme d’API REST authentifiées.
Exemple 2 (pour une administration): Le projet devra respecter le référentiel Général d’Interopérabilité (RGI).
|
Tip
|
L’archivage est la recopie de données importantes sur un support dédié offline en vue non pas d’une restauration comme la sauvegarde mais d’une consultation occasionnelle. Les archives sont souvent exigées pour des raisons légales et conservées trente ans ou plus. Précisez si des données de l’application doivent être conservées à long terme. Précisez les raisons de cet archivage (légales le plus souvent). Précisez si des dispositifs spécifiques de protection de l’intégrité (pour empêcher toute modification principalement) doivent être mis en place. |
Exemple 1: comme exigé par l’article L.123-22 du code de commerce, les données comptables devront être conservées au moins dix ans.
Exemple 2 : Les pièces comptables doivent être conservées en ligne (en base) au moins deux ans puis peuvent être archivées pour conservation au moins dix ans de plus. Une empreinte SHA256 sera calculée au moment de l’archivage et stockée séparément pour vérification de l’intégrité des documents en cas de besoin.
|
Tip
|
Précisez ici combien de temps doivent être conservées les données et documents persistés par vos modules applicatifs. À noter que ces durées peuvent être contraintes par le droit (voir contraintes juridiques plus haut), par exemple dans le cadre du droit à l’oubli du RGPD. |
|
Tip
|
Ne pas oublier de mentionner les données techniques (comme les logs ou les tables techniques) ainsi que les archives. |
Exemple :
| Donnée | Durée maximale de rétention |
|---|---|
Données de paiement (CB) |
2 mois |
Liste des commandes |
2 ans |
Logs d’accès |
1 mois |
Archives des données comptables |
30 ans |
|
Tip
|
Présenter ici l’application dans son ensemble (sans détailler ses sous-composants) en relation avec les autres applications du SI. Présenter également les macro-données échangées ou stockées. Rappeler :
Si l’application est prévue pour être implémentée en plusieurs étapes, décrire succinctement la trajectoire cible. |
|
Tip
|
Le choix de la représentation est libre mais un diagramme C4 de System Landscape ou un diagramme de composant UML2 semble le plus adapté. Numéroter les étapes par ordre chronologique assure une meilleure compréhension du schéma. Grouper les sous étapes par la notation x, x.y, x.y.z, … Ne pas faire figurer les nombreux systèmes d’infrastructure (serveur SMTP, dispositif de sécurité, reverse proxy, annuaires LDAP, …) qui sont du domaine de l’architecture technique. Mentionner en revanche les éventuels bus d’entreprise qui ont un rôle applicatif (orchestration de service par exemple). |
Exemple 1 : MesInfosEnLigne permet à une entreprise de récupérer par mail un document récapitulant toutes les informations dont l’administration dispose sur elle. L’administration peut compléter ses données par celles d’une autre administration.
Exemple 2 : MesInfosEnLigne est constituée de plusieurs microservices indépendants (composants IHM, batchs ou services REST)
Exemple 3 : Suite à la dérogation du DSI le 03 aout 20xx, l’IHM sera en architecture SPA (Single Page Application)
|
Tip
|
Détailler ici tous les composants de l’application, leurs flux entre eux et avec les autres applications du SI. Proposer un ou plusieurs schémas (de préférence des diagrammes C4 de type containers ou diagramme UML2 de composant). Idéalement, le schéma tiendra sur une page A4, sera autoporteur et compréhensible par un non-technicien. Il devrait devenir l’un des artefacts documentaires les plus importants et figurer dans la war room d’un projet agile ou être imprimé par chaque développeur. Si l’application est particulièrement complexe, faire un schéma par chaîne de liaison. Utiliser comme ID des flux une simple séquence non signifiante (1, 2, …, n). Les flux sont logiques et non techniques (par exemple, on peut représenter un flux HTTP direct entre deux composants alors qu’en réalité, il passe par un répartiteur de charge intermédiaire : ce niveau de détail sera donné dans la vue infrastructure). Pour chaque flux, donner le protocole, un attribut synchrone/asynchrone, un attribut lecture/écriture/exécution et une description pour que le schéma soit auto-porteur. |
|
Tip
|
Donner ici l’intention dans la construction de l’architecture. |
Exemple : nous utiliserons une approche monolithique et non micro-service par manque d’expertise.
|
Tip
|
Exposer les modules applicatifs dans leurs différentes zones ou domaines. |
Exemple: module X, Y et Z dans le domaine GED. Modules A, B dans le domaine PERSONNE.
|
Tip
|
Exposer les modules applicatifs dans leurs différentes zones ou domaines avec leurs flux applicatifs principaux. Ne pas détailler les flux techniques (comme les flux liés à la supervision ou au clustering). Si l’application est complexe, proposer un schéma global exposant tous les flux applicatifs puis un schéma par chaîne de liaison principale en numérotant les échanges (utiliser un diagramme de séquence ou (mieux) un Dynamic Diagram C4). Il est possible également de détailler les chaînes de liaison par fonctionnailité principale. |
Exemple:
|
Tip
|
Décrire ici les dispositifs permettant de répondre aux exigences d’archivage. Cette section contiendra principalement :
|
Exemple : les relevés bancaires de plus de 10 ans seront archivés sur bande LTO et disque dur. Un jeu de chacun des deux supports sera stocké en coffre dans deux banques différentes.
|
Tip
|
Donner ici les dispositifs techniques répondant aux exigences de purge. |
Exemple 1: L’historique des consultations sera archivé par un dump avec une requête SQL de la forme COPY (SELECT * FROM ma_table WHERE …) TO '/tmp/dump.tsv' puis purgé par une requête SQL DELETE après validation par l’exploitant de la complétude du dump.
Exemple 2: Chaque API est responsable de la purge des données qu’elle expose. Pour cela, prévoir des traitements internes qui suppriment les données suivant une planification (expression cron) et des critères paramétrables.
|
Tip
|
Lister ici les flux principaux de l’application. Ne pas détailler les flux techniques de supervision ou liés au clustering par exemple. Mentionner le type de réseau (LAN, WAN). |
| Source | Destination | Type de réseau | Protocole | Mode.[1] |
|---|---|---|---|---|
Entreprise |
PC/tablette/mobile externe |
WAN |
ihm-miel |
LE |
batch-traiter-demandes |
service-compo-pdf |
LAN |
HTTP |
A |